原则网站设计版式seo网络优化平台
0 前言
在使用 Docker 的过程中，编写 Dockerfile 是非常重要的一部分工作。合理编写 Dockerfile 会使我们构建出来的 Docker image 拥有更佳的性能和健壮性
目标:
- 更快的构建速度
- 更小的 Docker 镜像大小
- 更少的 Docker 镜像层
- 充分利用镜像缓存
- 增加 Dockerfile 可读性
- 让 Docker 容器使用起来更简单
总结
- 编写.dockerignore 文件
- 容器只运行单个应用
- 将多个 RUN 指令合并为一个
- 基础镜像的标签不要用 latest
- 每个 RUN 指令后删除多余文件
- 选择合适的基础镜像 (alpine 版本最好)
- 设置 WORKDIR 和 CMD
- 使用 ENTRYPOINT (可选)
- 在 entrypoint 脚本中使用 exec
- COPY 与 ADD 优先使用前者
- 合理调整 COPY 与 RUN 的顺序
- 设置默认的环境变量，映射端口和数据卷
- 使用 LABEL 设置镜像元数据
- 添加 HEALTHCHECK
可以说每条 Dockerfile 指令都有相关的优化项，这里就不一一赘述了，下面仅列举一些常见且重要的设置
1 容器的优雅退出
众所周知，docker 容器本质上是一个个进程，进程的优雅退出需要考虑的是如何正确处理 SIGTERM 信号，关于这点在我的另一篇博文中介绍过 kill命令详解以及linux中的信号
无论是 docker stop 还是在 kubernetes 中使用容器，一般关闭容器都是向容器内的 1 号进程发送 SIGTERM 信号，等待容器自行进行资源清理等操作，等待时间 docker 默认 10s，k8s 默认 30s，如果容器仍未退出，则发送 SIGKILL 信号强制杀死进程
综上，我们只需要考虑 2 点
- 应用程序如何处理信号
这就需要在应用程序中定义对信号的处理逻辑了，包括对每个信号如何处理如何转发给子进程等。
- 应用程序如何获取信号
docker 容器的一号进程是由 CMD ENTRYPOINT 这两个指令决定的，所以正确使用这两个指令十分关键
CMD 和 ENTRYPOINT 分别都有 exec 和 shell 两种格式：
- 使用
exec格式时，我们执行的命令就是一号进程 - 使用
shell格式时，实际会以/bin/sh -c command arg…的方式运行，这种情况下容器的一号进程将会是/bin/sh，当收到信号时/bin/sh不会将信号转发给我们的应用程序，导致意料之外的错误，所以十分不推荐使用shell格式
我们还可以使用 tini 作为 init 系统管理进程
官方地址：https://github.com/krallin/tini
Tini (Tiny but Independent) 是一个小型的、可执行的程序，它的主要目的是作为一个 init 系统的替代品，用于在容器中启动应用程序。
在容器中启动应用程序时，通常会使用 init 系统来管理进程。然而，由于容器的特殊性，传统的 init 系统可能无法完全满足容器化应用程序的需求。Tini 作为一个小巧而独立的程序，可以帮助解决容器启动时可能遇到的各种问题，如僵尸进程、信号处理等。
在 Docker 中使用 Tini 的主要意义在于提高容器的稳定性和可靠性。Tini 可以确保容器中的应用程序在启动和退出时正确处理信号，避免僵尸进程和其它常见问题的出现。此外，Tini 还可以有效地限制容器中的资源使用，避免应用程序崩溃或者占用过多的系统资源，从而提高容器的可用性和可维护性。
总之，使用 Tini 可以让容器中的应用程序更加健壮、稳定和可靠，这对于运行生产环境中的应用程序非常重要。
使用示例
FROM nginx
ENV TINI_VERSION=v0.19.0
ADD https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini /tini
RUN chmod +x /tini
ENTRYPOINT ["/tini", "--", "/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]
Alpine Linux
RUN apk add --no-cache tini
# Tini is now available at /sbin/tini
ENTRYPOINT ["/sbin/tini", "--"]
NixOS
Debian
Arch Linux
2 RUN 指令
RUN 指令一般用于安装配置软件包等操作，通常需要比较多的步骤，如果每条命令都单独用 RUN 指令去跑会导致镜像层数非常多，所以尽可能将所有 RUN 指令拼接起来是当前的事实标准
也要将 RUN 指令中生产的一些附属文件删除以缩小最终镜像的大小
如下示例
FROM debian:stretchRUN set -x; buildDeps='gcc libc6-dev make wget' \&& apt-get update \&& apt-get install -y $buildDeps \&& wget -O redis.tar.gz "http://download.redis.io/releases/redis-5.0.3.tar.gz" \&& mkdir -p /usr/src/redis \&& tar -xzf redis.tar.gz -C /usr/src/redis --strip-components=1 \&& make -C /usr/src/redis \&& make -C /usr/src/redis install \&& rm -rf /var/lib/apt/lists/* \&& rm redis.tar.gz \&& rm -r /usr/src/redis \&& apt-get purge -y --auto-remove $buildDeps
3 多阶段构建
很多时候我们的应用容器会包含 构建 和 运行 两大功能，而运行所需要的依赖数量明显少于构建时的依赖，我们最终的 image 交付物有运行环境就足够了
在很多的场景中，我们都会制作两个 Dockerfile 分别用于构建和运行，文件交付起来十分麻烦
在 Docker Engine 17.05 中引入了多阶段构建，以此降低构建复杂度，同时使缩小镜像尺寸更为简单
如下示例，go 程序编译完后几乎不需要任何依赖环境即可运行
# 阶段1
FROM golang:1.16
WORKDIR /go/src
COPY app.go ./
RUN go build app.go -o myapp# 阶段2，引用空镜像 scratch
FROM scratch
WORKDIR /server
# 复制文件，通过编号引用，0 代表阶段 1
COPY --from=0 /go/src/myapp ./
CMD ["./myapp"]
上述例子可以修改一下，可读性更强
# 阶段1命名为builder
FROM golang:1.16 as builder
WORKDIR /go/src
COPY app.go ./
RUN go build app.go -o myapp# 阶段2，引用空镜像 scratch
FROM scratch
WORKDIR /server
# 复制文件，通过名称引用
COPY --from=builder /go/src/myapp ./
CMD ["./myapp"]
只构建某个阶段
构建镜像时，不一定需要构建整个 Dockerfile，我们可以通过 --target 参数指定某个目标阶段构建，比如我们开发阶段我们只构建 builder 阶段进行测试。
docker build --target builder -t builder_app:v1 .
使用外部镜像
COPY --from httpd:latest /usr/local/apache2/conf/httpd.conf ./httpd.conf
从上一阶段创建新的阶段
# 阶段1命名为builder
FROM golang:1.16 as builder
WORKDIR /go/src
COPY app.go ./
RUN go build app.go -o myapp# 阶段2，引用阶段1再进行一次构建
FROM builder as builder_ex
ADD dest.tar ./
...