docker的两类存储资源
Docker 为容器提供了两种存放数据的资源:
- 由 storage driver 管理的镜像层和容器层。
- Data Volume。
storage driver
先回顾一下docker的镜像分层结构:
容器由最上面一个可写的容器层,以及若干只读的镜像层组成,容器的数据就存放在这些层中。这样的分层结构最大的特性是 Copy-on-Write:
- 新数据会直接存放在最上面的容器层。
- 修改现有数据会先从镜像层将数据复制到容器层,修改后的数据直接保存在容器层中,镜像层保持不变。
- 如果多个层中有命名相同的文件,用户只能看到最上面那层中的文件。
分层结构使镜像和容器的创建、共享以及分发变得非常高效,而这些都要归功于 Docker storage driver。正是 storage driver 实现了多层数据的堆叠并为用户提供一个单一的合并之后的统一视图。
Docker 支持多种 storage driver,有 AUFS、Device Mapper、Btrfs、OverlayFS、VFS 和 ZFS。它们都能实现分层的架构,同时又有各自的特性。对于 Docker 用户来说,具体选择使用哪个 storage driver 是一个难题,因为:
- 没有哪个 driver 能够适应所有的场景。
- driver 本身在快速发展和迭代。
不过 Docker 官方给出了一个简单的答案:
优先使用 Linux 发行版默认的 storage driver。
Redhat/CentOS 的默认 driver 是xfs
对于某些容器,直接将数据放在由 storage driver 维护的层中是很好的选择,比如那些无状态的应用。无状态意味着容器没有需要持久化的数据,随时可以从镜像直接创建。
但对于另一类应用这种方式就不合适了,它们有持久化数据的需求,容器启动时需要加载已有的数据,容器销毁时希望保留产生的新数据,也就是说,这类容器是有状态的。
data volume
Data Volume 本质上是 Docker Host 文件系统中的目录或文件,能够直接被 mount 到容器的文件系统中。Data Volume 有以下特点:
- Data Volume 是目录或文件,而非没有格式化的磁盘(块设备)。
- 容器可以读写 volume 中的数据。
- volume 数据可以被永久的保存,即使使用它的容器已经销毁。
好,现在我们有数据层(镜像层和容器层)和 volume 都可以用来存放数据,具体使用的时候要怎样选择呢?考虑下面几个场景:
- Database 软件 vs Database 数据
- Web 应用 vs 应用产生的日志
- 数据分析软件 vs input/output 数据
- Apache Server vs 静态 HTML 文件
相信大家会做出这样的选择:
- 前者放在数据层中。因为这部分内容是无状态的,应该作为镜像的一部分。
- 后者放在 Data Volume 中。这是需要持久化的数据,并且应该与镜像分开存放。
因为 volume 实际上是 docker host 文件系统的一部分,所以 volume 的容量取决于文件系统当前未使用的空间,目前还没有方法设置 volume 的容量。
在具体的使用上,docker 提供了两种类型的 volume:bind mount 和 docker managed volume。
bind mount
bind mount 是将 host 上已存在的目录或文件 mount 到容器。
[root@wjm ~]# docker run -it -v /opt:/usr/local --name mycentos1 centos /bin/bash
[root@379c978cb1ad /]# cd /usr/local
[root@379c978cb1ad local]# touch 1.txt
[root@379c978cb1ad local]# exit
exit
[root@wjm ~]# cd /opt/
[root@wjm opt]# ls
1.txt containerd
另外,bind mount 时还可以指定数据的读写权限,默认是可读可写,可指定为只读:
ro
设置了只读权限,在容器中是无法对 bind mount 数据进行修改的。只有 host 有权修改数据,提高了安全性。
除了 bind mount 目录,还可以单独指定一个文件:
bind mount 的使用直观高效,易于理解,但它也有不足的地方:bind mount 需要指定 host 文件系统的特定路径,这就限制了容器的可移植性,当需要将容器迁移到其他 host,而该 host 没有要 mount 的数据或者数据不在相同的路径时,操作会失败。
managed volume
managed volume 与 bind mount 在使用上的最大区别是不需要指定 mount 源,指明 mount point 就行了。还是以 httpd 容器为例:
通过 -v
告诉 docker 需要一个 data volume,并将其 mount 到 /usr/local/apache2/htdocs。那么这个 data volume 具体在哪儿呢?
docker inspect 21accc2ca072
"Mounts": [
{
"Name": "f4a0a1018968f47960efe760829e3c5738c702533d29911b01df9f18babf3340",
"Source": "/var/lib/docker/volumes/f4a0a1018968f47960efe760829e3c5738c702533d29911b01df9f18babf3340/_data",
"Destination": "/usr/local/apache2/htdocs",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
每当容器申请 mount docker manged volume 时,docker 都会在/var/lib/docker/volumes
下生成一个目录
volume 的内容跟容器原有 /usr/local/apache2/htdocs 完全一样,这是怎么回事呢?
这是因为:如果 mount point 指向的是已有目录,原有数据会被复制到 volume 中。
来看下两者的区别:
volume container
volume container 是专门为其他容器提供 volume 的容器。它提供的卷可以是 bind mount,也可以是 docker managed volume。下面我们创建一个 volume container:
我们将容器命名为 vc_data
(vc 是 volume container 的缩写)。注意这里执行的是 docker create
命令,这是因为 volume container 的作用只是提供数据,它本身不需要处于运行状态。容器 mount 了两个 volume:
- bind mount,存放 web server 的静态文件。
- docker managed volume,存放一些实用工具(当然现在是空的,这里只是做个示例)。
通过 docker inspect
可以查看到这两个 volume。
# docker inspect vc_data
"Mounts": [
{
"Source": "/root/htdocs",
"Destination": "/usr/local/apache2/htdocs",
"Mode": "",
"RW": true,
"Propagation": "rprivate"
},
{
"Name": "1b603669398d117e499449862636a56c4f4c804d447c680e7b3ba7c7f5e52205",
"Source": "/var/lib/docker/volumes/1b603669398d117e499449862636a56c4f4c804d447c680e7b3ba7c7f5e52205/_data",
"Destination": "/other/useful/tools",
"Driver": "local",
"Mode": "",
"RW": true,
"Propagation": ""
}
],
其他容器可以通过 --volumes-from
使用 vc_data
这个 volume container:
下面我们讨论一下 volume container 的特点:
- 与 bind mount 相比,不必为每一个容器指定 host path,所有 path 都在 volume container 中定义好了,容器只需与 volume container 关联,实现了容器与 host 的解耦。
- 使用 volume container 的容器其 mount point 是一致的,有利于配置的规范和标准化,但也带来一定的局限,使用时需要综合考虑。
data-packed volume container
volume container 的数据归根到底还是在 host 里,有没有办法将数据完全放到 volume container 中,同时又能与其他容器共享呢?
当然可以,通常我们称这种容器为 data-packed volume container。其原理是将数据打包到镜像中,然后通过 docker managed volume 共享。
我们用下面的 Dockfile 构建镜像:
ADD
将静态文件添加到容器目录 /usr/local/apache2/htdocs。VOLUME
的作用与 -v
等效,用来创建 docker managed volume,mount point 为 /usr/local/apache2/htdocs,因为这个目录就是 ADD
添加的目录,所以会将已有数据拷贝到 volume 中。
build 新镜像 datapacked:
用新镜像创建 data-packed volume container:
因为在 Dockerfile 中已经使用了 VOLUME
指令,这里就不需要指定 volume 的 mount point 了。启动 httpd 容器并使用 data-packed volume container:
容器能够正确读取 volume 中的数据。data-packed volume container 是自包含的,不依赖 host 提供数据,具有很强的移植性,非常适合 只使用 静态数据的场景,比如应用的配置信息、web server 的静态文件等。
Dockerfile详解
FROM
语法:
FROM <image>
FROM <image>:<tag>
FROM <image>:<digest>
RUN
RUN命令有两种格式:
shell格式:RUN <command>
exec格式: RUN ["executable", "param1", "param2"]
两种写法对比:
RUN /bin/bash -c 'source $HOME/.bashrc; echo $HOME'
RUN ["/bin/bash", "-c", "echo hello"]
注意:多行命令不要写多个RUN,原因是Dockerfile中每一个指令都会建立一层
CMD
1. CMD ["executable","param1","param2"]
2. CMD ["param1","param2"]
3. CMD command param1 param2
第一种和第二种其实都是可执行文件加上参数的形式
CMD [ "sh", "-c", "echo $HOME"
CMD [ "echo", "$HOME" ]
补充细节:这里边包括参数的一定要用双引号,就是",不能是单引号。千万不能写成单引号。
原因是参数传递后,docker解析的是一个JSON array
ENTRYPOINT
类似于 CMD 指令,但其不会被 docker run 的命令行参数指定的指令所覆盖,而且这些命令行参数会被当作参数送给 ENTRYPOINT 指令指定的程序。
但是, 如果运行 docker run 时使用了 --entrypoint 选项,将覆盖 ENTRYPOINT 指令指定的程序。
优点:在执行 docker run 的时候可以指定 ENTRYPOINT 运行所需的参数。
注意:如果 Dockerfile 中如果存在多个 ENTRYPOINT 指令,仅最后一个生效。
格式:
ENTRYPOINT ["<executeable>","<param1>","<param2>",...]
可以搭配 CMD 命令使用:一般是变参才会使用 CMD ,这里的 CMD 等于是在给 ENTRYPOINT 传参,以下示例会提到。
实例:
FROM nginx
ENTRYPOINT ["nginx", "-c"] # 定参
CMD ["/etc/nginx/nginx.conf"] # 变参
1、不传参运行
$ docker run nginx:test
容器内会默认运行以下命令,启动主进程。
nginx -c /etc/nginx/nginx.conf
2、传参运行
$ docker run nginx:test -c /etc/nginx/new.conf
容器内会默认运行以下命令,启动主进程(/etc/nginx/new.conf:假设容器内已有此文件)
nginx -c /etc/nginx/new.conf
最佳实践:
- 使用 RUN 指令安装应用和软件包,构建镜像。
- 如果 Docker 镜像的用途是运行应用程序或服务,比如运行一个 MySQL,应该优先使用 Exec 格式的 ENTRYPOINT 指令。CMD 可为 ENTRYPOINT 提供额外的默认参数,同时可利用 docker run 命令行替换默认参数。
- 如果想为容器设置默认的启动命令,可使用 CMD 指令。用户可在 docker run 命令行中替换此默认命令。
MAINTAINER
指定作者
MAINTAINER <name>
EXPOSE
构建镜像暴露的端口,也就是启动容器以后,容器的端口。
如果想使得容器与主机的端口有映射关系,必须在容器启动的时候加上 -P参数
ENV
功能为设置环境变量
语法有两种
1. ENV <key> <value>
2. ENV <key>=<value> ...
两者的区别就是第一种是一次设置一个,第二种是一次设置多个
ADD
一个复制命令,把文件复制到景象中。
1. ADD <src>... <dest>
2. ADD ["<src>",... "<dest>"]
路径的填写可以是容器内的绝对路径,也可以是相对于工作目录的相对路径
可以是一个本地文件或者是一个本地压缩文件,还可以是一个url
如果把写成一个url,那么ADD就类似于wget命令,如果是压缩文件会自动解压至容器内部。
ADD test relativeDir/
ADD test /relativeDir
ADD http://example.com/foobar /
尽量不要把写成一个文件夹,如果是一个文件夹了,复制整个目录的内容,包括文件系统元数据
COPY
1. COPY <src>... <dest>
2. COPY ["<src>",... "<dest>"]
与ADD的区别
COPY的只能是本地文件,不做解压
VOLUME
可实现挂载功能,可以将内地文件夹或者其他容器种得文件夹挂在到这个容器种
USER
设置启动容器的用户,可以是用户名或UID
WORKDIR
语法:
WORKDIR /path/to/workdir
ARG
语法:
ARG <name>[=<default value>]
设置变量命令,ARG命令定义了一个变量,在docker build创建镜像的时候,使用 --build-arg =来指定参数
我们可以定义一个或多个参数:
FROM busybox
ARG user1
ARG buildno
...
也可以给参数一个默认值:
FROM busybox
ARG user1=someuser
ARG buildno=1
...
ONBUILD
语法:
ONBUILD [INSTRUCTION]
这个命令只对当前镜像的子镜像生效。
比如当前镜像为A,在Dockerfile种添加:
ONBUILD RUN ls -al
这个 ls -al 命令不会在A镜像构建或启动的时候执行
此时有一个镜像B是基于A镜像构建的,那么这个ls -al 命令会在B镜像构建的时候被执行。
STOPSIGNAL
语法:
STOPSIGNAL signal
STOPSIGNAL命令是的作用是当容器推出时给系统发送什么样的指令
HEALTHCHECK
容器健康状况检查命令
语法有两种:
1. HEALTHCHECK [OPTIONS] CMD command
2. HEALTHCHECK NONE
- 第一个的功能是在容器内部运行一个命令来检查容器的健康状况
- 第二个的功能是在基础镜像中取消健康检查命令
[OPTIONS]的选项支持以下三中选项:
–interval=DURATION 两次检查默认的时间间隔为30秒
–timeout=DURATION 健康检查命令运行超时时长,默认30秒
–retries=N 当连续失败指定次数后,则容器被认为是不健康的,状态为unhealthy,默认次数是3
注意:
HEALTHCHECK命令只能出现一次,如果出现了多次,只有最后一个生效。
CMD后边的命令的返回值决定了本次健康检查是否成功,具体的返回值如下:
0: success - 表示容器是健康的
1: unhealthy - 表示容器已经不能工作了
2: reserved - 保留值
#######################每一个不曾起舞的日子,都是对生命的辜负#####################