容器(Docker)第三章：实战使用

最新推荐文章于 2022-09-15 14:48:31 发布

置顶 Aabin⁶⁶⁶

最新推荐文章于 2022-09-15 14:48:31 发布

阅读量576

点赞数 1

分类专栏： Docker PaaS 文章标签： Docker 容器

本文链接：https://blog.csdn.net/jona_li/article/details/94293583

版权

Docker 同时被 2 个专栏收录

5 篇文章 0 订阅

订阅专栏

PaaS

5 篇文章 0 订阅

订阅专栏

Author: Lijb
Email: lijb1121@163.com
WeChat: ljb1121

走进Docker

Docker File

容器化的第一步就是制作镜像，不过，相较于之前介绍的制作 rootfs 的过程，Docker 为你提供了一种更便捷的方式，叫作 Dockerfile，如下所示。

# 使用官方提供的 Python 开发镜像作为基础镜像 
FROM python:2.7-slim 
 
# 将工作目录切换为 /app 
WORKDIR /app 
 
# 将当前目录下的所有内容复制到 /app 下 
ADD . /app 

# 使用 pip 命令安装这个应用所需要的依赖 
RUN pip install --trusted-host pypi.python.org -r requirements.txt 
 
# 允许外界访问容器的 80 端口 
EXPOSE 80 
 
# 设置环境变量 
ENV NAME World 
 
# 设置容器进程为：python app.py，即：这个 Python 应用的启动命令 
CMD ["python", "app.py"]

1. Dockerfile是放在项目根目录，和src是同级关系，并且名称就是Dockerfile,我一开始写成了Dockerfile.txt结果完美报错。
2. Dockerfile内容中前面大写的是指令，后面跟参数
		FROM  指明基础镜像是谁
		WORKDIR，意思是在这一句之后，Dockerfile 后面的操作都以这一句指定的 /app 目录作 为当前目录。
		ADD ，它指的是把当前目录（即 Dockerfile 所在的目录）里的文件，复制到指定容器内的目录当中。
		MAINTAINER 指明项目的作者信息
		COPY 复制文件到镜像中 
		RUN 会生成容器，
		CMD 设置容器的启动命令 （有的项目启动时需要加一些指令，例如prometheus启动的时候不指明prometheus.yml的路径时远程无法post访问）
		EXPOSE 指明docker中的应用在运行的时候可以访问的端口号

镜像

读懂这个 Dockerfile 之后，我再把上述内容，保存到当前目录里一个名叫“Dockerfile”的文件中：

创建镜像

$ docker build -t helloworld .
-t 的作用是给这个镜像加一个 Tag，即：起一个好听的名字
. 代表当前路径

# 说明：docker build 会自动加载 当前目录下的 Dockerfile 文件，然后按照顺序，执行文件中的原语。而这个过程，实际上可以 等同于 Docker 使用基础镜像启动了一个容器，然后在容器中依次执行 Dockerfile 中的原语。

查看镜像

$ docker image ls 
 
REPOSITORY            TAG                 IMAGE ID helloworld         latest              653287cdf998

启动镜像

$ docker run -p 4000:80 helloworld
# 通过 -p 4000:80 告诉了 Docker，请把容器内的 80 端口映射在宿主机的 4000 端口上。
# 这样做的目的是，只要访问宿主机的 4000 端口，我就可以看到容器里应用返回的结果：

$ curl http://localhost:4000 
<h3>Hello World!</h3><b>Hostname:</b> 4ddf4638572d<br/> 
# 否则，我就得先用 docker inspect 命令查看容器的 IP 地址，然后访问“http://< 容器 IP 地址 >:80”才可以看到容器内应用的返回。

因为在 Dockerfile 中已经指定了 CMD。否则，我就得把进程的启动命令加在后面：

$ docker run -p 4000:80 helloworld python app.py

把镜像上传到DockerHub上

$ docker tag helloworld lijb/helloworld:v1 

# lijb 是在 Docker Hub 上的用户名，它的“学名”叫镜像仓库 （Repository）；“/”后面的 helloworld 是这个镜像的名字，而“v1”则是给这个镜像分 配的版本号。

$ docker push geektime/helloworld:v1

此外，我还可以使用 docker commit 指令，把一个正在运行的容器，直接提交为一个镜像。一般来说，需要这么操作原因是：这个容器运行起来后，我又在里面做了一些操作，并且要把操作结果保存到镜像里，比如：

# docker exec 命令进入到了容器当中
$ docker exec -it 4ddf4638572d /bin/sh  

# 在容器内部新建了一个文件
root@4ddf4638572d:/app# touch test.txt 
root@4ddf4638572d:/app# exit 
 
# 将这个新建的文件提交到镜像中保存 
$ docker commit 4ddf4638572d geektime/helloworld:v2

docker commit

1. docker commit，实际上就是在容器运行起来后，把上层的“可读写层”，加上原先容器镜 像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，不会占用 额外的空间。

2. 而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被操作系统先复 制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。

3. 而正如前所说，Init 层的存在，就是为了避免你执行 docker commit 时，把 Docker 自己对 /etc/hosts 等文件做的修改，也一起提交掉

proc 文件

实际上，Linux Namespace 创建的隔离空间虽然看不见摸不着，但一个进程的 Namespace 信息在宿主机上是确确实实存在的，并且是以一个文件的方式存在。

查看当前正在运行的 Docker 容器的进程号（PID）是 25686

$ docker inspect --format '{{ .State.Pid }}'  4ddf4638572d 
25686

查看宿主机的 proc 文件，看到这个 25686 进程的所有 Namespace 对应的文件：

可以看到，一个进程的每种 Linux Namespace，都在它对应的 /proc/[进程号]/ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。

$ ls -l  /proc/25686/ns 
total 0 
lrwxrwxrwx 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 0 Aug 13 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]

结论

1. 因为宿主机的 proc 文件，一个进程可以选择加入到某个进程已有的 Namespace 当中,从而达到“进 入”这个进程所在容器的目的.

2. 一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也会有所体现,这正是 docker exec 的实现原理

详解Linux Namespace

一个进程可以选择加入到某个进程已有的 Namespace 当中,从而达到“进入”这个进程所在容器的目的，而这个操作所依赖的，是一个名叫 setns() 的 Linux 系统调用。

调用方法

#define _GNU_SOURCE 
#include <fcntl.h> 
#include <sched.h> 
#include <unistd.h> 
#nclude <stdlib.h> 
#include <stdio.h> 
 
#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0) 
 
int main(int argc, char *argv[]) {  

	int fd;          
	fd = open(argv[1], O_RDONLY); 
    
	if (setns(fd, 0) == -1) { 
    	errExit("setns");     
    }     
    
    execvp(argv[2], &argv[2]);      
    errExit("execvp"); 
    
 }

分析

1. 它一共接收两个参数，第一个参数是 argv[1]，即当前进程要加入的 Namespace 文件的路径，比如 /proc/25686/ns/net；而第二个参数，则是你要在这个 Namespace 里运行的进程，比如 /bin/bash。

2. 这段代码的的核心操作，则是通过 open() 系统调用打开了指定的 Namespace 文件，并把这个文件的描述符 fd 交给 setns() 使用。在 setns() 执行后，当前进程就加入了这个文件对应的 Linux Namespace 当中了。

编译执行一下这个程序，加入到容器进程（PID=25686）的 Network Namespace 中：

$ gcc -o set_ns set_ns.c  
$ ./set_ns /proc/25686/ns/net /bin/bash  
$ ifconfig 
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02             
		  inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0           
		  inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link           
		  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           
		  RX packets:12 errors:0 dropped:0 overruns:0 frame:0           
		  TX packets:10 errors:0 dropped:0 overruns:0 carrier:0     
		  collisions:0 txqueuelen:0            
		  RX bytes:976 (976.0 B)   TX bytes:796 (796.0 B) 
 
 
lo        Link encap:Local Loopback             
		  inet addr:127.0.0.1  Mask:255.0.0.0           
		  inet6 addr: ::1/128 Scope:Host           
		  UP LOOPBACK RUNNING  MTU:65536  Metric:1          
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0           
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0    
          collisions:0 txqueuelen:1000            
          RX bytes:0 (0.0 B)  	TX bytes:0 (0.0 B)

结果

正如上所示，当我们执行 ifconfig 命令查看网络设备时，我会发现能看到的网卡“变少”了： 只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢？

实际上，在 setns() 之后我看到的这两个网卡，正是前面启动的 Docker 容器里的网卡。也就是说，新创建的这个 /bin/bash 进程，由于加入了该容器进程（PID=25686）的 Network Namepace，它看到的网络设备与这个容器里是一样的，即：/bin/bash 进程的网络设备视 图，也被修改了。

证实了前面结论：一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也会有所体现。

在宿主机上，可以用 ps 指令找到这个 set_ns 程序执行的 /bin/bash 进程，其真实的 PID 是 28499：

# 在宿主机上 
ps aux | grep /bin/bash 

root     28499  0.0  0.0 19944  3612 pts/0    S    14:15   0:00 /bin/bash

查看一下这个 PID=28499 的进程的 Namespace

$ ls -l /proc/28499/ns/net lrwxrwxrwx 1 root root 0 Aug 13 14:18 /proc/28499/ns/net -> net:[4026532281] 
 
$ ls -l  /proc/25686/ns/net lrwxrwxrwx 1 root root 0 Aug 13 14:05 /proc/25686/ns/net -> net:[4026532281]

在 /proc/[PID]/ns/net 目录下，这个 PID=28499 进程，与我们前面的 Docker 容器进程（PID=25686）指向的 Network Namespace 文件完全一样。这说明这两个进程，共享了这个名叫 net:[4026532281] 的 Network Namespace。
此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的 Network Namespace 里，这个参数就是 -net，比如:

$ docker run -it --net container:4ddf4638572d busybox ifconfig

这样，我们新启动的这个容器，就会直接加入到 ID=4ddf4638572d 的容器，也就是我们前面的创建的 Python 应用容器（PID=25686）的 Network Namespace 中。所以，这里 ifconfig 返回的网卡信息，跟我前面那个小程序返回的结果一模一样。
而如果指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提供了一个渠道。

Volume

思考

容器里进程新建的文件，怎么才能让宿主机获取到？
宿主机上的文件和目录，怎么才能让容器里的进程访问到？

Volume 机制

Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改操作。在 Docker 项目里，它支持两种 Volume 声明方式，可以把宿主机目录挂载进容器的 /test 目录当中：

$ docker run -v /test ... 

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

这两种声明方式的本质，实际上是相同的：都是把一个宿主机的目录挂载进了容器的 /test 目 录。

1. 在第一种情况下，由于你并没有显示声明宿主机目录，那么 Docker 就会默认在宿主机 上创建一个临时目录 /var/lib/docker/volumes/[VOLUME_ID]/_data，然后把它挂载到容器的 /test 目录上。

2. 第二种情况下，Docker 就直接把宿主机的 /home 目录挂载到容器的 /test 目录上。

当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。

而宿主机上的文件系统，也自然包括了我们要使用的容器镜像。这个镜像的各个层，保存在 /var/lib/docker/aufs/diff 目录下，在容器进程启动后，它们会被联合挂载在 /var/lib/docker/aufs/mnt/ 目录中，这样容器所需的 rootfs 就准备好了。

所以，我们只需要在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作就完成了。

更重要的是，由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就保证了容器的隔离性不会被 Volume 打破。

注意

这里提到的 " 容器进程 "，是 Docker 创建的一个容器初始化进程 (dockerinit)，而不是应用进程 (ENTRYPOINT + CMD)。dockerinit 会负责完成 根目录的准备、挂载设备和目录、配置 hostname 等一系列需要在容器内进行的 初始化操作。后，它通过 execv() 系统调用，让应用进程取代自己，成为容器里 的 PID=1 的进程。

要使用到的挂载技术，就是 Linux 的绑定挂载（Bind Mount）机制。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。

其实，如果你了解 Linux 内核的话，就会明白，绑定挂载实际上是一个 inode 替换的过程。在 Linux 操作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”

正如上图所示，mount --bind /home /test，会将 /home 挂载到 /test 上。其实相当于将 /test 的 dentry，重定向到了 /home 的 inode。这样当我们修改 /test 目录时，实际修改的是 /home 目录的 inode。这也就是为何，一旦执行 umount 命令，/test 目录原先的内容就会恢复：因为修改真正发生在的，是 /home 目录里。
所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件，不动声色地挂载到容器中。

这样，进程在容器里对这个 /test 目录进行的所有操作，都实际发生在宿主机的对应目录（比如，/home，或者 /var/lib/docker/volumes/[VOLUME_ID]/_data）里，而不会影响容器镜像的内容。
那么，这个 /test 目录里的内容，既然挂载在容器 rootfs 的可读写层，它会不会被 docker commit 提交掉呢？
也不会。

这个原因其实我们前面已经提到过。容器的镜像操作，比如 docker commit，都是发生在宿主机空间的。而由于 Mount Namespace 的隔离作用，宿主机并不知道这个绑定挂载的存在。所以，在宿主机看来，容器中可读写层的 /test 目录（/var/lib/docker/aufs/mnt/[可读写层 ID]/test），始终是空的。

不过，由于 Docker 一开始还是要创建 /test 这个目录作为挂载点，所以执行了 docker commit 之后，你会发现新产生的镜像里，会多出来一个空的 /test 目录。毕竟，新建目录操作，又不是挂载操作，Mount Namespace 对它可起不到“障眼法”的作用。

验证

首先，启动一个 helloworld 容器，给它声明一个 Volume，挂载在容器里的 /test 目录上

$ docker run -d -v /test helloworld 

cf53b766fa6f

来查看一下这个 Volume 的 ID

$ docker volume ls DRIVER              

VOLUME NAME 

local  cb1c2f7221fa9b0971cc35f68aa1034824755ac44a034c0c0a1dd318838d3a6d

然后，使用这个 ID，可以找到它在 Docker 工作目录下的 volumes 路径

$ ls /var/lib/docker/volumes/cb1c2f7221fa/_data/ 

# 这个 _data 文件夹，就是这个容器的 Volume 在宿主机上对应的临时目录了。

在容器的 Volume 里，添加一个文件 text.txt

$ docker exec -it cf53b766fa6f /bin/sh

cd test/ touch 

text.txt

再回到宿主机，就会发现 text.txt 已经出现在了宿主机上对应的临时目录里

$ ls /var/lib/docker/volumes/cb1c2f7221fa/_data/ 

text.txt

如果你在宿主机上查看该容器的可读写层，虽然可以看到这个 /test 目录，但其内容是空的

$ ls /var/lib/docker/aufs/mnt/6780d0778b8a/test

结论

容器 Volume 里的信息，并不会被 docker commit 提交掉；但这个挂载点目录 /test 本身，则会出现在新的镜像当中

Docker总结

Docker全景图

1. 这个容器进程“python app.py”，运行在由 Linux Namespace 和 Cgroups 构成的隔离环境里；

2. 而它运行所需要的各种文件，比如 python，app.py，以及整个操作系统文件，则由多个联 合挂载在一起的 rootfs 层提供。

3. 这些 rootfs 层的下层，是来自 Docker 镜像的只读层。在只读层之上，是 Docker 自己添加的 Init 层，用来存放被临时修改过的 /etc/hosts 等文件。

4. 而 rootfs 的上层是一个可读写层，它以 Copy-on-Write 的方式存放任何对只读层的修改， 容器声明的 Volume 的挂载点，也出现在这一层。

Docker是一个由Linux Namespace 、Linux Cgroups和rootfs三大核心技术实现的虚拟化容器技术，其中Linux Namespace实现了Docker进程的隔离性、Linux Cgroups达到了Docker使用资源的限制性、rootfs保证了Docker运行环境的一致性。

Aabin⁶⁶⁶

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
容器(Docker)第三章：实战使用

Author: LijbEmail: lijb1121@163.comWeChat: ljb1121走进DockerDocker File容器化的第一步就是制作镜像，不过，相较于之前介绍的制作 rootfs 的过程，Docker 为你提供了一种更便捷的方式，叫作 Dockerfile，如下所示。# 使用官方提供的 Python 开发镜像作为基础镜像 FROM python:2.7-s...
复制链接

扫一扫

专栏目录