Shulou(Shulou.com)06/03 Report--

"in-depth Analysis of Kubernetes-08 | vernacular Container Foundation (4): re-understanding Docker Container"

1. Dockerfile production

The common way to make rootfs: Dockerfile

# use the official Python development image as the basic image FROM python:2.7-slim# to change the working directory to / appWORKDIR / app# and copy all the contents under the current directory to ADD under / app. / app# uses the pip command to install the dependent RUN pip install needed to install the application-- trusted-host pypi.python.org-r requirements.txt# allows the outside world to access the container's port 80 EXPOSE 8 settings environment variable ENV NAME World# sets the container process to: python app.py, that is, the startup command CMD of the Python application ["python", "app.py"]

Note:

1. ENTRYPOINT and CMD are necessary parameters for container startup. Docker will provide a default ENTRYPOINT: / bin/sh-c, so if you do not specify ENTRYPOINT, specify CMD directly. In fact, the command executed is / bin/sh-c CMD.

2. The difference between ADD and COPY: ADD can decompress automatically if a compressed package is added, but COPY will not

3. Each instruction generates a corresponding mirror layer, so when writing RUN, you can write multiple commands through connectors to avoid generating too many mirror layers, such as:

RUN ln-s / data/services/nginx / usr/local/nginx & &\ mkdir-p / data/weblog/nginx & &\ / etc/init.d/nginx start

After the dockerfile is created, use the following command to build the image (in the directory where the Dockerfile resides)

# docker build-t test-images.

Then upload it to the image repository via docker push

# docker tag test-images test/nginx:1.14.2 # docker push test/nginx:1.14.2

You can also create a container image through commit, as follows

Docker exec-it 4ddf4638572d / bin/sh# created a new file inside the container root@4ddf4638572d:/app# touch test.txtroot@4ddf4638572d:/app# exit# to submit the newly created file to the image to save $docker commit 4ddf4638572d geektime/helloworld:v2

Docker commit is actually in the container, plus the top read-write layer, as well as the original image in the read-only layer to form a mirror. The read-only layer is shared on the host and does not take up extra space.

According to the federated file system, any changes made on the mirrored rootfs are replicated one layer at the top and then modified on that basis, which is called copy on write.

2. The principle of docker exec.

The process executed by the container can be seen on the host machine. After seeing the process pid through PS (assuming 25686), you can see all the files corresponding to ns in the / proc/25686/ns directory.

Ls-l / proc/25686/nstotal 0lrwxrwxrwx 1 root root 0 Aug 13 14:05 cgroup-> cgroup: [4026531835] lrwxrwxrwx 1 root root 0 Aug 13 14:05 ipc-> ipc: [4026532278] lrwxrwxrwx 1 root root 0 Aug 13 14:05 mnt-> mnt: [4026532276] lrwxrwxrwx 1 root root 0 Aug 13 14:05 net-> net: [4026532281] lrwxrwxrwx 1 root root 0 Aug 13 14:05 pid-> pid: [4026532279] lrwxrwxrwx 1 root root 013 Aug 14:05 pid_for_children-> pid: 4026532279] lrwxrwxrwx 1 root root 0 Aug 13 14:05 user-> user: [4026531837] lrwxrwxrwx 1 root root 0 Aug 13 14:05 uts-> uts: [4026532277]

The process can then be added to the corresponding ns through the system call of setns ().

Setns () requires two parameters. The first parameter is the path of the namespace file to be added, such as / proc/25686/ns/net; the second parameter is the program to be executed, such as / bin/bash

When you specify-- net=host when docker starts, the container does not start network namespace for the process when it starts, and the container shares a network stack with the host.

3. Voluem implementation mechanism

It mainly solves the problem of file interworking between host and container, such as:

(1) how to access the files generated by the container on the host machine

(2) how the container accesses the files on the host

On docker, you can do this in two ways

$docker run-v / test... $docker run-v / home:/test.

The first method is equivalent to creating a temp directory locally in the host, and then mounting it to the container's / test directory

The second way is to mount the / home directory on the host to the container's / test directory

In essence, linux's bind mount mechanism is used, and its main purpose is to allow a directory or file to be mounted to a specified directory instead of the device. The principle is a process of inode replacement. In linux, inode stores the object of the file contents, while dentry stores pointers to this object. So the process of mounting is actually to modify the pointer to point to another inode, and then to point the pointer back to the original inode when the umount is executed.

Note:

1. Actions done on the mount directory will not affect the source directory

2. The modification of the mount directory will not take effect when docker commit is executed, only the corresponding empty directory will be created.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.