Docker 容器的高级优化

1、缩小镜像

极大的减少下载或上传的网络 I/O
在能保证镜像环境能够稳定运行的基础上，有效的减小镜像的大小，当镜像足够多少其意义重大（生产环境）。
可以缩小镜像的对象 使用编译性代码编写的代码（C、JAVA、GO）
不可以缩小镜像的对象 使用解释性代码编写的代码（Python） 代码的运行需要环境支持

1.1、镜像构建原理

Docker Daemon 通过 Dockerfile 构建镜像时，当发现即将新构建出的镜像与已有的某镜像重复时，可以选择放弃构建新的镜像，而是选用已有的镜像作为构建结果，也就是采取本地已经 cache 的镜像作为结果，导致构建的镜像不是最新的版本。

1.2、cache 机制的注意事项

①、 ADD 命令与 COPY 命令：

Dockerfile 没有发生任何改变，但是命令ADD run.sh / 中 Dockerfile 当前目录下的 run.sh 却发生了变化，从而将直接导致镜像层文件系统内容的更新，原则上不应该再使用 cache。那么，判断 ADD 命令或者 COPY 命令后紧接的文件是否发生变化，则成为是否延用 cache 的重要依据。Docker 采取的策略是：获取 Dockerfile 下内容（包括文件的部分 inode 信息），计算出一个唯一的 hash 值，若 hash 值未发生变化，则可以认为文件内容没有发生变化，可以使用 cache 机制；反之亦然。

②、 RUN 命令存在外部依赖：

一旦 RUN 命令存在外部依赖，如RUN apt-get update，那么随着时间的推移，基于同一个基础镜像，一年的 apt-get update 和一年后的 apt-get update， 由于软件源软件的更新，从而导致产生的镜像理论上应该不同。如果继续使用 cache 机制，将存在不满足用户需求的情况。Docker 一开始的设计既考虑了外部依赖的问题，用户可以使用参数 --no-cache 确保获取最新的外部依赖，
格式：docker build --no-cache -t [容器名]:[tag] .
docker build --no-cache -t=“my_new_image” .

③、树状的镜像关系决定了，一次新镜像的成功构建将导致后续的 cache 机制全部失效：

这一点很好理解，一旦产生一个新的镜像，同时意味着产生一个新的镜像 ID，而当前宿主机环境中肯定不会存在一个镜像，此镜像 ID 的父镜像 ID 是新产生镜像的ID。这也是为什么，书写 Dockerfile 时，应该将更多静态的安装、配置命令尽可能地放在 Dockerfile 的较前位置
为了防止在构建镜像时引用旧的镜像文件，使用 --no-cache 的选项

1.3、传统 build 流程

# 使用 Go 语言编写的判断内链和外链的类型
内链：一个网站中链接到网站内部的链接；
外链：一个网站中链接到外部网站的链接；
外链越多网络优化越难。
# SEO：网络优化
# first step
FROM golang:1.7.3
WORKDIR /go/src/github.com/sparkdevo/href-counter/
# 获取依赖包
RUN go get -d -v golang.org/x/net/html
# 复制 app.go 的源码
COPY app.go .
# 将源码编译为可执行文件
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

# second step
# 提供最精简的 Linux 镜像
FROM alpine:</