Docker

致谢

把这篇博客献给我的朋友@RMB122。

没有他无数次向我安利 Docker ，就不会有这篇博客，感谢他。

疑问

为什么Docker快速轻量？

传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。

Docker是如何做到的？

Namespaces 实现隔离

在 Docker 中每当我们每次运行 docker run 或者 docker start 时，都会 createSpec 创建一个用于设置进程间隔离的 Spec 。

在 createSpec 的 setNamespaces 方法中不仅会设置进程相关的命名空间，还会设置与用户、网络、IPC 以及 UTS 相关的命名空间。

在创建新进程时传入 CLONE_NEWPID ，也就是使用 Linux 的命名空间来实现进程的隔离，Docker 容器内部的任意进程都对宿主机器的进程一无所知。

PID namespaces用来隔离进程的ID空间，使得不同pid namespace里的进程ID可以重复且相互之间不影响。

PID namespace可以嵌套，也就是说有父子关系，在当前namespace里面创建的所有新的namespace都是当前namespace的子namespace。父namespace里面可以看到所有子孙后代namespace里的进程信息，而子namespace里看不到祖先或者兄弟namespace里的进程信息。

网络暴露

当 Docker 服务器在主机上启动之后会创建新的虚拟网桥 docker0，随后在该主机上启动的全部服务在默认情况下都与该网桥相连。

docker0 会为每一个容器分配一个新的 IP 地址并将 docker0 的 IP 地址设置为默认的网关。网桥 docker0 通过 iptables 中的配置与宿主机器上的网卡相连，所有符合条件的请求都会通过 iptables 转发到 docker0 并由网桥分发给对应的机器。

Tips：在 Docker 使用过程中，我们可能需要用到不同的容器间通信，这时宿主机的 IP 不再是 127.0.0.1 ，而是 docker0 的 IP 地址。

文件系统隔离

为了保证当前的容器进程没有办法访问宿主机器上其他目录，我们在这里还需要通过 libcontainer 提供的 pivot_root 或者 chroot 函数改变进程能够访问个文件目录的根节点。

Control Groups/CGroups

Control Groups（简称 CGroups）就是能够隔离宿主机器上的物理资源，例如 CPU、内存、磁盘 I/O 和网络带宽。

在 CGroup 中，所有的任务就是一个系统的一个进程，而 CGroup 就是一组按照某种标准划分的进程，在 CGroup 这种机制中，所有的资源控制都是以 CGroup 作为单位实现的，每一个进程都可以随时加入一个 CGroup 也可以随时退出一个 CGroup。

启动容器时，Docker 会为这个容器创建一个与容器标识符相同的 CGroup。

每一个 CGroup 下面都有一个 tasks 文件，其中存储着属于当前控制组的所有进程的 pid，作为负责 cpu 的子系统。

应用

镜像

Docker采用Union FS技术设计了分层储存的架构，一个镜像即为多层文件系统联合组成。

镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。比如，删除前一层文件的操作，实际不是真的删除前一层的文件，而是仅在当前层标记为该文件已删除。在最终容器运行的时候，虽然不会看到这个文件，但是实际上该文件会一直跟随镜像。因此，在构建镜像的时候，需要额外小心，每一层尽量只包含该层需要添加的东西，任何额外的东西应该在该层构建结束前清理掉。

分层储存使得镜像的复用变得更加容易。

容器

每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为 容器存储层。

按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入操作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

虚悬镜像

仓库名及标签名均为 <none> 的镜像即为虚悬镜像，虚悬镜像是因为新版本替代了旧版本而使用相同的仓库名及标签名造成的，可以使用 docker image prune 命令清除。

慎用 commit 命令

不要使用 docker commit 定制镜像，定制镜像应该使用 Dockerfile 来完成。

commit 可以应用在一些特殊的场合，比如被入侵后保存现场等。

在分层存储的架构下，除当前层外，之前的每一层都是不会发生改变的。换句话说，任何修改的结果仅仅是在当前层进行标记、添加、修改，而不会改动上一层。如果使用 docker commit 制作镜像，以及后期修改的话，每一次修改都会让镜像更加臃肿一次，所删除的上一层的东西并不会丢失，会一直如影随形的跟着这个镜像，即使根本无法访问到。这会让镜像更加臃肿。

Dockerfile

Dockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。

FROM 用于指定镜像基础

服务类的镜像，如nginx、redis、mongo、mysql、httpd、php、tomcat 等。

语言类的镜像，如 node、openjdk、python、ruby、golang 等。

操作系统镜像，如 ubuntu、debian、centos、fedora、alpine 等。

如果你以 scratch 为基础镜像的话，意味着你不以任何镜像为基础，接下来所写的指令将作为镜像第一层开始存在。

RUN 用于执行命令

两种格式：

Shell：RUN <命令>

Exec：RUN ["可执行文件", "参数1", "参数2"]

注意，Dockerfile 中每一个指令都会建立一层镜像，建议在一条 Run 语句中尽可能多地运行指令，以减少不必要的层数增加。

在Run命令准备结束时，我们需要删除为了编译构建而下载的软件，清理所有下载、展开的文件，清理 apt 缓存文件。

这是很重要的一步，我们之前说过，镜像是多层存储，每一层的东西并不会在下一层被删除，会一直跟随着镜像。因此镜像构建时，一定要确保每一层只添加真正需要添加的东西，任何无关的东西都应该清理掉。

ADD 和 COPY 用于复制文件

在 Docker 官方的 Dockerfile 最佳实践文档 中要求，尽可能的使用 COPY，因为 COPY 的语义很明确，就是复制文件而已，而 ADD 则包含了更复杂的功能，其行为也不一定很清晰。最适合使用 ADD 的场合，就是所提及的需要自动解压缩的场合。

另外需要注意的是，ADD 指令会令镜像构建缓存失效，从而可能会令镜像构建变得比较缓慢。

因此在 COPY 和 ADD 指令中选择的时候，可以遵循这样的原则，所有的文件复制均使用 COPY 指令，仅在需要自动解压缩的场合使用 ADD。

CMD 用于指定主进程启动命令

Docker 不是虚拟机，容器中的应用都应该以前台执行，而不是像虚拟机、物理机里面那样，用 systemd 去启动后台服务，容器内没有后台服务的概念。

例如，使用 service nginx start 命令，则是希望 upstart 来以后台守护进程形式启动 nginx 服务。而刚才说了 CMD service nginx start 会被理解为 CMD [ "sh", "-c", "service nginx start"]，因此主进程实际上是 sh。那么当 service nginx start 命令结束后，sh 也就结束了，sh 作为主进程退出了，自然就会令容器退出。

ENTRYPOINT 入口点

在运行 docker run 命令后，跟在镜像名后面的是 command，运行时会替换 CMD 的默认值，所以为了在 CMD 命令后添加命令参数，就需要使用 ENTRYPOINT 。

当存在 ENTRYPOINT 后，CMD 的内容将会作为参数传给 ENTRYPOINT，而跟在镜像名后面命令就是新的 CMD。

ENV 环境变量设置

这个指令很简单，就是设置环境变量而已，无论是后面的其它指令，如 RUN，还是运行时的应用，都可以直接使用这里定义的环境变量。

ARG 构建参数

构建参数和 ENV 的效果一样，都是设置环境变量。所不同的是，ARG 所设置的构建环境的环境变量，在将来容器运行时是不会存在这些环境变量的。但是不要因此就使用 ARG 保存密码之类的信息，因为 docker history 还是可以看到所有值的。

VOLUME 定义匿名卷

使用 VOLUME /data 后，这里的 /data 目录就会在运行时自动挂载为匿名卷，任何向 /data 中写入的信息都不会记录进容器存储层，从而保证了容器存储层的无状态化。

EXPOSE 声明端口

EXPOSE 指令是声明运行时容器提供服务端口，这只是一个声明，在运行时并不会因为这个声明应用就会开启这个端口的服务。

要将 EXPOSE 和在运行时使用 -p <宿主端口>:<容器端口> 区分开来。-p，是映射宿主端口和容器端口，换句话说，就是将容器的对应端口服务公开给外界访问，而 EXPOSE 仅仅是声明容器打算使用什么端口而已，并不会自动在宿主进行端口映射。

WORKDIR 指定工作目录

使用 WORKDIR 指令可以来指定工作目录（或者称为当前目录），以后各层的当前目录就被改为指定的目录，如该目录不存在，WORKDIR 会帮你建立目录。

因为两条 RUN 命令之间间隔了一层镜像，即 RUN cd /home 命令后下一条语句并不会进入到 /home ，此时需要使用 WORKDIR 。

Bulid 构建镜像

Docker 采用了 C/S 结构，也就是说我们在使用 docker build 命令的时候，并非在本地构建镜像，而是在服务端，也就是 Docker 引擎中构建的。

当我们进行镜像构建的时候，并非所有定制都会通过 RUN 指令完成，经常会需要将一些本地文件复制进镜像，比如通过 COPY 指令、ADD 指令等。那么在这种客户端/服务端的架构中，如何才能让服务端获得本地文件呢？

这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，docker build 命令得知这个路径后，会将路径下的所有内容打包，然后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后，展开就会获得构建镜像所需的一切文件。

一般来说，应该将 Dockerfile 置于一个空目录下，或者项目根目录下。如果该目录下没有所需文件，那么应该把所需文件复制一份过来。如果目录下有些东西确实不希望构建时传给 Docker 引擎，那么可以用 .gitignore 一样的语法写一个 .dockerignore，该文件是用于剔除不需要作为上下文传递给 Docker 引擎的。

Dockerfile 多阶段构建

例如，我们要使用 Docker 运行以下程序：

1
2
3
4
5
6
7
package main

import "fmt"

func main(){
    fmt.Printf("Hello World!");
}

使用以下写法会导致 Docker 镜像过大以及暴露源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
FROM golang:1.9-alpine

RUN apk --no-cache add git ca-certificates

WORKDIR /go/src/github.com/go/helloworld/

COPY app.go .

RUN go get -d -v github.com/go-sql-driver/mysql \
  && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app . \
  && cp /go/src/github.com/go/helloworld/app /root

WORKDIR /root/

CMD ["./app"]

推荐使用写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
FROM golang:1.9-alpine as builder

RUN apk --no-cache add git

WORKDIR /go/src/github.com/go/helloworld/

RUN go get -d -v github.com/go-sql-driver/mysql

COPY app.go .

RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest as prod

RUN apk --no-cache add ca-certificates

WORKDIR /root/

COPY --from=0 /go/src/github.com/go/helloworld/app .

CMD ["./app"]

也就是说，我们只需要编译后的程序的话，应该开启另一个镜像，并加载上一阶段的产物。

Docker Compose

Docker Compose 是由 Python 编写，实现上调用了 Docker 服务提供的 API 来对容器进行管理。

强烈安利

Dockerfile 最佳实践

Reference