一、回顾12要素之进程

• 运行环境中，应用程序通常是以一个和多个进程运行的。
• 12-Factor 应用的进程必须无状态（Stateless）且无共享（Share nothing）。
• 任何需要持久化的数据都要存储在后端服务内，比如数据库。
• 应在构建阶段将源代码编译成待执行应用。
• Session Sticky 是 12-Factor 极力反对的。
• Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间 的缓存中。

Docker 遵循以上原则管理和构建应用。

二、理解构建上下文（Build Context）

• 当运行 docker build 命令时，当前工作目录被称为构建上下文。
• docker build 默认查找当前目录的 Dockerfile 作为构建输入，也可以通过 –f 指定 Dockerfile。
  • docker build –f ./Dockerfile
• 当 docker build 运行时，首先会把构建上下文传输给 docker daemon，把没用的文件包含在构建上下文时，会导致传输时间长，构建需要的资源多，构建出的镜像大等问题。
  • 试着到一个包含文件很多的目录运行下面的命令，会感受到差异；
  • docker build -f $GOPATH/src/github.com/cncamp/golang/httpserver/Dockerfile ；
  • docker build $GOPATH/src/github.com/cncamp/golang/httpserver/；
  • 可以通过.dockerignore文件从编译上下文排除某些文件。
  • 因此需要确保构建上下文清晰，比如创建一个专门的目录放置 Dockerfile，并在目录中运行 docker build。

三、Build Cache

构建容器镜像时，Docker 依次读取 Dockerfile 中的指令，并按顺序依次执行构建指令。 Docker 读取指令后，会先判断缓存中是否有可用的已存镜像，只有已存镜像不存在时才会重新构建。

• 通常 Docker 简单判断 Dockerfile 中的指令与镜像
• 针对 ADD 和 COPY 指令，Docker 判断该镜像层每一个文件的内容并生成一个 checksum，与现存镜像比较时，Docker 比较的是二者的 checksum。
• 其他指令，比如 RUN apt-get -y update，Docker 简单比较与现存镜像中的指令字串是否一致。
• 当某一层 cache 失效以后，所有所有层级的 cache 均一并失效，后续指令都重新构建镜像。