Detailed introduction and analysis of Docker characteristics and principles _docker

Docker Characteristics and principle

First take a look at what features Docker offers:

1. Interactive Shell:docker can assign a virtual terminal and associate it to any container's standard input, such as running a one-time interactive shell
2. File system isolation: Each process container runs in a completely separate root file system
3. Write-time replication: Create a root file system using write-time replication, which makes deployment extremely fast and saves memory and hard disk space
4. Resource isolation: You can use Cgroup to assign different system resources to each process container
5. Network isolation: Each process container runs in its own network namespace with its own virtual interface and IP address
6. Logging: Docker will collect and record the standard stream (Stdout/stderr/stdin) for each process container for real-time retrieval or bulk retrieval
7. Change Management: Container file system changes can be committed to new images and reused to create more containers. No use of templates or manual configuration
   

From the above characteristics to see the principle of implementation

1. Interactive shell

First, we allow an interactive container

$docker run-i-T <image name>/bin/bash

This creates an interactive connection to the container and sees the following command line:

root@df3880b17407:/#

Here we start a container with bash as its root process.

root@df3880b17407:/# PS aux 
USER    PID%cpu%mem  VSZ  RSS TTY   STAT START time  COMMAND
root     1 0.0 0.0 18164 2020?    S  06:06  0:00/bin/bash

As you can see, in this container,Bash has a PID of 1, which is normally the case for a solid machine:

root@ubuntu:~# PS aux 
USER    PID%cpu%mem  VSZ  RSS TTY   STAT START time  COMMAND
root< c21/>1 0.0 0.1 24716 2612?    Ss  Sep04  0:01/sbin/init

As we all know, the common ancestor of all processes is the pid=1 process

So in the container, all the processes created later are created by/bin/bash, and Pid=1 's bash is understood by the ancestors of all the processes in the container, and the understanding of the container is simple.

2. File System Isolation

For a running container, the file system is a virtual file system that starts at the root directory, as seen in the container:

 Ll/total drwxr-xr-x 2 root root 4096 root@df3880b17407:/# 22:51 bin Drwxr-x R-x 2 root 4096 Apr 22:12 boot drwxr-xr-x 3 root root 4096 June 22:49 Dev drwxr-xr-x-root root 4096 Sep 5 0 6:49 etc drwxr-xr-x 2 root 4096 Apr 22:12 home drwxr-xr-x root root 4096 22:50 lib Drwxr-xr-x 2 root R
oot 4096 Aug 03:30 lib64 drwxr-xr-x 2 root 4096 June 22:48 media drwxr-xr-x 2 root root 4096 Apr 22:12 mnt Drwxr-xr-x 2 root 4096 22:48 opt dr-xr-xr-x 356 root 0 Sep 5 06:06 proc drwx------2 root root 4096 Ju L-22:51 Root drwxr-xr-x 7 root 4096 Sep 5 07:23 run drwxr-xr-x 2 root root 4096 Aug 03:30 sbin drwxr-xr-x 2 Root root 4096 22:48 srv dr-xr-xr-x root root 0 Sep 5 06:06 sys drwxrwxrwt 2 root root 4096 Sep 5 06:55 tmp Dr Wxr-xr-x root root 4096 Sep 5 06:11 usr drwxr-xr-x root root 4096 Sep 5 06:11 var 

In fact, this is the case, the file system in the container is mounted to the real system under a directory.

/var/lib/docker/containers/<image-long-id>/rootfs

This configuration is how to come, in fact, all container management is through LXC to manage, LXC's configuration file in

/var/lib/docker/containers/<image-long-id>/config.lxc

There are fields in the file that indicate which file directory The container is mounted to, such as mine:

Lxc.rootfs =/var/lib/docker/containers/df3880b17407575cd642a6b7da3c7e417a55fad5bbd63152f89921925626d2b6/rootfs

Open Look, glance:

Root@ubuntu:/var/lib/docker/containers/df3880b17407575cd642a6b7da3c7e417a55fad5bbd63152f89921925626d2b6/rootfs # ll Total drwxr-xr-x root root 4096 Sep 5 00:23./drwx------4 root 4096 Sep 5 00:53.  /drwxr-xr-x 2 root 4096 15:51 bin/drwxr-xr-x 2 root 4096 Apr 15:12 boot/drwxr-xr-x 3 root root 4096  June 15:49 Dev/drwxr-xr-x-root 4096 Sep 4 23:49 etc/drwxr-xr-x 2 root root 4096 Apr 15:12 home/drwxr-xr-x Root root 4096 June 15:50 lib/drwxr-xr-x 2 root 4096 Aug-20:30 lib64/drwxr-xr-x 2 root root 4096 June 22 15 : media/drwxr-xr-x 2 root 4096 Apr 15:12 mnt/drwxr-xr-x 2 root root 4096 June 15:48 Opt/drwxr-xr-x 2 root R oot 4096 APR 15:12 proc/drwx------2 root 4096 June 15:51 root/drwxr-xr-x 7 root root 4096 Sep 5 00:23 RUN/DR  Wxr-xr-x 2 root 4096 Aug 20:30 sbin/drwxr-xr-x 2 root root 4096 June 15:48 srv/drwxr-xr-x 2 root 4096 Mar 18:41 SYS/DRWXRWXRWT 2 root 4096 Sep 4 23:55 TMP/drwxr-xr-x root root 4096 Sep 4 23:11 usr/drwxr-xr-x root root 4096 Sep 4 23:11
 

These are the real directories in the container, and the operation of the directory in the container is the real directory of the host machine.
For different containers, the mount point is not the same, and the container can not traverse the root level to access, so here for each container are file system isolation.

3. Copy at write time

We put every

/var/lib/docker/containers/<image-long-id>

As a container configuration directory, you can see that there is a rw/directory under the configuration directory, open to see what

Total
drwxr-xr-x 9 root 4096 Sep 5 00:23./
drwx------4 root 4096 Sep 5 00:53. /
drwxr-xr-x 6 root 4096 Sep 4 23:49 etc/
drwxr-xr-x 2 root 4096 Sep 5 00:23 run/
DRWXRWXRWT 2 root Root 4096 Sep 4 23:55 tmp/
drwxr-xr-x 7 root root 4096 Sep 4 23:11 usr/
drwxr-xr-x 5 root root 4096 Sep 4 23:11 VA r/
-r--r--r--1 root  0 Sep 4 23:06. Wh. Wh.aufs
drwx------2 root 4096 Sep 4 23:06. Wh. wh.orph/
drwx------2 root 4096 Sep 4 23:11. Wh. wh.plnk/

The inside is some incomplete root directory, which doesn't explain anything, but after we write the file in container, look at the changes.

Execute the following command in the container

root@df3880b17407:/# touch/opt/x

Under the /opt , we generated a file

Look again.

root@ubuntu:/var/lib/docker/containers/df3880b17407575cd642a6b7da3c7e417a55fad5bbd63152f89921925626d2b6/rw# LL Total
drwxr-xr-x root 4096 Sep 5 01:00./
drwx------4 root 4096 Sep 5 00:53. /
drwxr-xr-x 6 root 4096 Sep 4 23:49 etc/
drwxr-xr-x 2 root 4096 Sep 5 01:00 opt/
drwxr-xr-x 2 root Root 4096 Sep 5 00:23 run/
DRWXRWXRWT 2 root root 4096 Sep 4 23:55 tmp/
drwxr-xr-x 7 root root 4096 Sep 4 23:11 US r/
drwxr-xr-x 5 root 4096 Sep 4 23:11 var/-r--r--r--
1 root  0 Sep 4 23:06. wh. Wh.aufs
drwx------2 root 4096 Sep 4 23:06. Wh. wh.orph/
drwx------2 root 4096 Sep 4 23:11. Wh. wh.plnk/

Yes, on the host machine The new life became the opt/directory, where the container was written to copy

4. Resource Isolation

A message queue that communicates between the three main processes of the system

Initial state in Ghost, ipcs-q view Message Queue

root@ubuntu:~/codes/msq# ipcs-q

------message queues--------
key    msqid   owner   perms   Used-bytes  Messages  

Create a message queue in Ghost , where the landlord writes his own code:

root@ubuntu:~/codes/msq#./main 1
Create msq with key ID 65536root@ubuntu:~/codes/msq# ipcs-q

------Message Q Ueues--------
Key    msqid   owner   perms   used-bytes  messages  
0x00000001 65536   Root    666    0      0      

Then view the ipcs-q in the container

root@df3880b17407:/# ipcs-q

------message queues--------
key    msqid   owner   perms   Used-bytes  Messages 

You can see that the system resources are isolated, and this is only part of it, but it also includes quota management that can be CPU and memory through Cgoup.
By default, all CPU and memory are used, but you can add the following configuration settings CPU in Config.lxc, and refer to LXC documentation

lxc.cgroup.cpu.shares=512 lxc.cgroup.cpuset.cpus=1.2

The principle of resource isolation lies in the use of Cgroup, isolate the use of different processes, assuming that each container is started with bash, within the container, each child process can only use the resources below the current bash and is isolated for other system resources. Access to child processes is determined by the parent process

5. Network Isolation

After the Docker is installed, a DOCKER0 bridge is initialized by default

Docker0  Link encap:ethernet hwaddr ee:8c:1f:8b:d7:59 inet addr:172.17.42.1 bcast:0.0.0.0 mask:255.255.0.0
     ...

On the host machine, a default NIC is generated for each container similar to vethdbva1h veth*

One end of this NIC is connected to the eth0 of the container and one end is connected to the DOCKER0. This enables each container to have a separate IP.

Here, if you need a container to access the extranet, you need to set the eth0 to promiscuous mode:

$ifconfig eth0 Promisc

In this way, the container will select an IP as the eth0 IP from the 172.17.0.0/24 segment, so that the container can communicate with the outside through the DOCKER0 Network Bridge.

Monitor a port inside the container python-m simplehttpserver >>/tmp/log.log &
From Ghost access Telnet 172.17.0.2 80
See the following in the container:

Active Internet connections (servers and established)
Proto recv-q send-q Local address      Foreign     address State    Pid/program name
TCP    0   0 0.0.0.0:80       0.0.0.0:*        LISTEN   2823/python   
TCP    0   0 172.17.0.2:80      172.17.42.1:46142    time_wait  - 

See on Host

Active Internet connections (servers and established)
Proto recv-q send-q Local address      Foreign     address State    Pid/program name
TCP    0   0 172.17.42.1:46142    172.17.0.2:80      established 10244/ Telnet

If you need to be able to access the container externally, need to do the port mapping rules, and the same as the configuration of virtual machines, but here you can see that the 80 port does not occupy the local port, but the inside of the container to do the monitoring, the external through the Docker0 bridge through the past, each container is also done between the port and network isolation.

6. Log records

Not much, under the/var/lib/docker/containers/<image-long-id>.log.

7. Change Management

Docker's change management is considered Git's version management.

When mirroring is generated, the part that has not been altered is a reference to the previous version of the Mirror, which, if changed, is a new file.

Mirror the container you just operated on

Docker commit <image-id> <REPOSITORY>

The part of the image that I have here, like I have Python installed in this image, is a new file, and the rest is still a reference to the previous version.

You can build your own mirror server, push it to your own mirror server, and pull it down from the other machine to run it directly.

Thank you for reading, I hope to help you, thank you for your support for this site!