锅总详解容器优化(一)

基础镜像如何选择？Dockerfile如何优化？CMD、ENTRYPOINT、ENV如何配合使用？容器的只读层、可读写层和init层有哪些内容？执行docker commit不会保存哪些内容？希望本文能带给您答案！

基础镜像选择

基础镜像（Base Image）是指 Docker 镜像中最底层的镜像，它为其他镜像的构建提供了基础的操作系统环境。基础镜像通常包含一个最小化的操作系统或运行时环境，是构建应用程序容器镜像的起点。

选择基础镜像的考虑因素

选择适合的基础镜像至关重要，因为它会直接影响容器的大小、性能、安全性和易用性。以下是选择基础镜像时需要考虑的几个因素：

1. 镜像大小：

   • 较小的镜像通常更快地下载、启动和部署。比如，alpine 镜像非常小巧，通常是几MB大小，非常适合需要最小化镜像大小的场景。

2. 操作系统类型：

   • 如果你的应用需要特定的操作系统特性，选择相应的操作系统镜像，如 ubuntu、debian 或 centos。

3. 依赖环境：

   • 如果你的应用依赖某种特定的语言或运行环境，可以选择预装了这些环境的镜像，如 python、node、openjdk。

4. 安全性：

   • 使用官方认证的基础镜像可以提高安全性，因为这些镜像通常经过更严格的测试和维护。对于安全性要求高的环境，可以选择经过特殊安全处理的镜像，如 bitnami 提供的镜像。

5. 社区支持：

   • 使用广泛的基础镜像通常拥有更好的文档和社区支持，如 ubuntu、debian 和 alpine。

常见的基础镜像

以下是一些常用的基础镜像及其特点：

1. Alpine

   • 大小：非常小，通常在 5MB 左右。
   • 特点：轻量级、只包含最基本的工具，非常适合需要极简容器的场景。
   • 用例：适用于需要控制容器大小的应用。

2. Ubuntu

   • 大小：相对较大，一般在 20MB 以上。
   • 特点：通用的 Linux 发行版，广泛使用，有大量的工具和包可用。
   • 用例：适合需要广泛软件支持的应用。

3. Debian

   • 大小：比 Ubuntu 稍小，通常在 15MB 左右。
   • 特点：稳定、安全，包管理系统与 Ubuntu 类似，提供丰富的包支持。
   • 用例：适合需要长期稳定性和安全更新的应用。

4. CentOS

   • 大小：较大，约 200MB 左右。
   • 特点：企业级 Linux 发行版，长生命周期和稳定性。
   • 用例：适用于企业级应用，特别是在需要与 RHEL 兼容的场景。

5. Language-specific 镜像

   • 例如：python, node, openjdk, golang 等。
   • 特点：预装了特定语言的运行时环境，方便直接运行应用程序代码。
   • 用例：适合需要特定编程语言支持的应用，如 Python 应用可以选择 python:alpine 作为基础镜像。

基础镜像选择示例

如果你正在开发一个 Python Web 应用，你可以选择 python:3.9-slim 作为基础镜像，这样你可以得到一个较小且预装了 Python 3.9 运行环境的镜像。

FROM python:3.9-slim

WORKDIR /app

COPY . /app

RUN pip install --no-cache-dir -r requirements.txt

EXPOSE 5000

CMD ["python", "app.py"]

这个 Dockerfile 使用了 python:3.9-slim 作为基础镜像，slim 版本比标准版本更小，但仍然提供了完整的 Python 运行环境。

通过选择合适的基础镜像，你可以更好地优化你的 Docker 容器，从而提高应用程序的性能、安全性和部署速度。

Dockerfile优化

优化 Dockerfile 可以减少镜像大小、提高构建速度和运行时性能。以下是一些常见的 Dockerfile 优化方法：

1. 选择合适的基础镜像

• 使用尽可能小的基础镜像，如 alpine 代替 ubuntu 或 debian。
• 根据应用需求选择合适的版本和变种，避免使用不必要的工具和库。

2. 最小化图像层

• 将多个命令合并成一行，以减少图像层的数量。例如：

  RUN apt-get update && apt-get install -y \
      package1 \
      package2 && \
      apt-get clean && rm -rf /var/lib/apt/lists/*
  

• 使用 && 将相关命令串联，避免生成多余的中间层。

3. 合理利用缓存

• 将变化频繁的命令（如 ADD、COPY）放在 Dockerfile 的底部，避免频繁重新构建前面的层。
• 如果某些依赖不常变化，将它们尽可能放在靠前的位置。

4. 清理构建过程中产生的临时文件

• 安装软件包后，及时清理缓存和临时文件，以减小镜像大小。例如：

  RUN apt-get update && apt-get install -y \
      build-essential && \
      apt-get clean && \
      rm -rf /var/lib/apt/lists/*
  

5. 使用多阶段构建（Multi-stage Builds）

• 通过多阶段构建，只将最终构建产物复制到最终镜像中，避免不必要的文件和依赖。例如：

  # 第一阶段: 构建应用
  FROM golang:1.16 AS builder
  WORKDIR /app
  COPY . .
  RUN go build -o myapp
  
  # 第二阶段: 生成最终镜像
  FROM alpine:latest
  COPY --from=builder /app/myapp /usr/local/bin/myapp
  CMD ["myapp"]
  

6. 优化运行时指令

• 使用合适的 CMD 或 ENTRYPOINT，确保容器在启动时不执行不必要的命令。
• 避免使用 RUN 执行会在运行时发生的操作，例如定时任务。

7. 利用 .dockerignore

• 在 .dockerignore 文件中排除不必要的文件和目录，以减少 COPY 指令的文件传输量。

8. 减少外部依赖

• 尽量将所有依赖打包在镜像中，避免运行时从外部下载资源，提升容器启动速度和可靠性。

9. 压缩和删除无用的文件

• 在 RUN 命令中使用工具压缩文件，删除不必要的文档、示例和测试数据。

10. 定期更新基础镜像

• 保持基础镜像和依赖项的更新，以确保安全性和性能。

通过这些优化策略，可以有效提高 Docker 容器的性能和可维护性。

CMD、ENTRYPOINT、ENV互相配合

CMD、ENTRYPOINT 和 ENV 是 Dockerfile 中的重要指令，理解它们的用法及相互之间的配合可以帮助你更好地控制容器的行为。

CMD 指令

• 功能：指定容器启动时默认要执行的命令或命令参数。
• 用法：通常作为默认命令，但可以被 docker run 命令行中指定的参数覆盖。
• 格式：
  • CMD ["executable", "param1", "param2"] （exec 格式，推荐）
  • CMD command param1 param2 （shell 格式）

ENTRYPOINT 指令

• 功能：设置容器启动时要执行的主命令，通常与 CMD 配合使用。
• 用法：ENTRYPOINT 不容易被覆盖，除非使用 docker run --entrypoint 显式覆盖。
• 格式：
  • ENTRYPOINT ["executable", "param1", "param2"] （exec 格式，推荐）
  • ENTRYPOINT command param1 param2 （shell 格式）

ENV 指令

• 功能：设置环境变量，可以在 Dockerfile 中为后续指令提供默认值，也可以在运行时通过 docker run -e 覆盖。
• 用法：用于为命令或应用程序提供默认的环境配置。
• 格式：
  • ENV key=value
  • ENV key value

CMD 与 ENTRYPOINT 的配合

CMD 和 ENTRYPOINT 通常配合使用，以实现更灵活的容器启动行为。典型的模式如下：

1. ENTRYPOINT + CMD：

   • ENTRYPOINT 用于定义固定的可执行文件或脚本。
   • CMD 用于传递默认参数，但可以在 docker run 时覆盖。

   例如：

   ENTRYPOINT ["/usr/bin/myapp"]
   CMD ["--help"]
   

   在这个例子中，容器启动时会运行 /usr/bin/myapp --help。如果运行时提供了参数，它会替换 CMD 的内容：

   docker run myimage --version  # 运行 /usr/bin/myapp --version
   

2. 可选参数的应用：

   • 如果需要容器启动时默认执行一个命令，但又允许用户通过命令行参数修改行为，可以使用 ENTRYPOINT 和 CMD 的组合。

   例如：

   ENTRYPOINT ["/usr/bin/myapp"]
   CMD ["--default-arg"]
   

   • 如果用户不提供任何参数，容器会执行 /usr/bin/myapp --default-arg。

   • 如果用户提供了参数，CMD 会被覆盖：

     docker run myimage --custom-arg  # 运行 /usr/bin/myapp --custom-arg
     

ENV 与 ENTRYPOINT、CMD 的配合

ENV 可以用来为 ENTRYPOINT 或 CMD 提供默认的配置值，增强其灵活性。

1. 在命令中使用环境变量：

   • 例如：

     ENV APP_ENV=production
     ENTRYPOINT ["/usr/bin/myapp"]
     CMD ["--env", "$APP_ENV"]
     

     在这个例子中，CMD 中的 $APP_ENV 会在容器运行时被替换为 production，即容器会执行 /usr/bin/myapp --env production。

2. 允许用户通过 docker run 覆盖 ENV：

   • 用户可以通过 -e 选项覆盖环境变量：

     docker run -e APP_ENV=staging myimage  # 运行 /usr/bin/myapp --env staging
     

CMD 可以只作为参数使用，尤其是在与 ENTRYPOINT 配合时。这种方式非常常见，ENTRYPOINT 指定主命令，而 CMD 则为这个命令提供默认的参数。

通过合理使用 CMD、ENTRYPOINT 和 ENV，你可以构建出具有灵活性和可定制性的 Docker 镜像，以适应不同的运行环境和需求。

容器的只读层、可读写层和init层

在 Docker 容器中，镜像和容器的文件系统由多个层次构成。这些层次包括只读层、可读写层和可选的 init 层（在某些高级场景下使用）。了解这些层次有助于更好地管理容器的持久化和性能优化。

1. 只读层 (Read-Only Layers)

• 组成：Docker 镜像是由多个只读层叠加而成的，每一层通常对应于 Dockerfile 中的一条指令（如 RUN、COPY 等）。
• 功能：这些层只读，不会被修改。每当镜像被拉取或构建时，这些只读层会被下载并缓存。
• 特点：
  • 不可变性：一旦镜像被构建完成，其所有只读层就不能再被修改。
  • 共享性：多个容器可以共享同一个镜像及其只读层，这使得 Docker 容器非常高效。

2. 可读写层 (Read-Write Layer)

• 组成：当一个容器从镜像启动时，Docker 会在镜像的顶部添加一个可读写层。这个层称为容器层。
• 功能：所有对容器文件系统的更改（如文件创建、修改或删除）都会发生在这个可读写层中。
• 特点：
  • 独立性：每个容器都有自己的可读写层，因此同一镜像启动的多个容器可以彼此独立地进行读写操作。
  • 非持久性：默认情况下，当容器停止或删除时，可读写层中的所有更改都会丢失。要持久化数据，需要使用 Docker 卷（Volumes）或绑定挂载（Bind Mounts）。

3. init 层（Init Layer）

• 定义：init 层并不是 Docker 的标准概念，而是特定情况下使用的一个术语，通常与某些高级功能或定制操作系统初始化过程相关。
• 功能：在某些情况下，用户可能会添加一个额外的初始化层，用于准备或初始化环境，这种层可以在容器启动前运行自定义的初始化脚本。
• 应用：
  • 在企业级容器中，可能需要对容器启动时进行一些初始化操作，如挂载特殊设备、设置环境变量或执行安全配置。
  • init 层可以通过 ENTRYPOINT 或 CMD 执行启动时的脚本，以确保容器启动前环境已经配置好。

容器文件系统操作流程

1. 文件读操作：

   • 当容器读取文件时，Docker 会从可读写层开始查找文件。如果文件存在于可读写层中，直接读取。
   • 如果文件不存在于可读写层，Docker 会继续向下查找，直到找到文件的只读层。

2. 文件写操作：

   • 当容器写入文件时，该操作会发生在可读写层。如果文件已存在于只读层，Docker 会将该文件从只读层复制到可读写层，并在可读写层进行修改。这种机制被称为“写时复制”（Copy-On-Write）。
   • 新创建的文件将直接写入可读写层。

3. 文件删除操作：

   • 删除操作不会真正移除只读层中的文件，而是在可读写层中标记为删除（即创建一个删除标记）。

容器层管理的影响

• 镜像复用：由于多个容器可以共享同一个镜像的只读层，Docker 可以大幅减少存储空间的使用。
• 性能考虑：写时复制和文件系统的层次结构可能会影响性能，尤其是在 I/O 密集型应用中。因此，了解和优化这些层的使用可以提升容器性能。

通过理解这些层次结构，你可以更好地设计和优化 Docker 容器，以实现更高效的资源使用和更好的性能表现。

执行docker commit不会保存哪些内容

在使用 docker commit 创建新镜像时，除了 hostname，还有一些其他的容器运行时配置和状态是不会被保存的。了解这些可以帮助你更好地管理和优化 Docker 镜像和容器。以下是一些不会被 docker commit 保存的容器属性和状态：

1. 运行时配置

• 网络配置：容器的网络设置（如 IP 地址、网络接口）不会被保存。网络配置是容器启动时由 Docker 网络驱动程序管理的。
• 端口映射：容器的端口映射设置（即 -p 参数）不会被保存。端口映射是运行时的设置，与容器的文件系统无关。
• 环境变量：容器启动时的环境变量设置（通过 -e 参数）不会被保存到镜像中。镜像只包含文件系统的状态，不包括容器的运行时环境。

2. 运行时状态

• 进程状态：容器内正在运行的进程状态不会被保存。docker commit 只保存容器文件系统的快照，不包括运行时的进程或内存状态。
• 临时文件和数据：容器运行时生成的临时文件和数据（如 /tmp 下的文件）不会被保存，除非这些文件在文件系统中已经持久化到镜像中。

3. 容器日志

• 日志文件：容器内的应用日志或系统日志文件不会被保存到镜像中。日志通常存储在容器内的文件系统中或由 Docker 的日志驱动程序管理。

4. 挂载卷（Volumes）

• 卷数据：与容器挂载的卷（Volumes）相关的数据不会被保存。卷用于持久化容器的数据，挂载的卷在容器重新创建后仍然存在，但这些数据不会被包含在新的镜像中。

5. 用户和权限

• 用户和组设置：容器的用户和组权限设置（如 USER 指令指定的用户）不会影响 docker commit 创建的镜像。镜像中保存的是文件系统的内容，而不是运行时的用户权限设置。

6. 容器运行参数

• 启动命令和参数：容器启动时的命令和参数（通过 docker run 的命令行选项传递）不会被保存。镜像本身只保存文件系统状态，而启动参数是运行时配置。

7. Docker 容器设置

• 容器的健康检查状态：容器的健康检查状态（如果使用了 HEALTHCHECK）不会被保存。健康检查是在容器运行时执行的，镜像中不会包含这些运行时的健康检查状态。

示例

如果你在一个容器中执行了一些操作，然后使用 docker commit 创建了一个新镜像，这些操作的结果（如创建的文件、修改的文件）会被保存到镜像中。但容器启动时的配置（如网络设置、端口映射）不会被包含在新镜像中。

总结

docker commit 是用于保存容器文件系统快照的工具，它不会保存运行时的配置和状态。为了确保容器的配置和数据持久化，建议使用 Docker 的其他功能（如 docker run 的选项、卷挂载、Docker Compose 配置等）来管理容器的运行时环境和数据。

如果本文对您有帮助，请点点关注点点赞，谢谢支持！
更多文章将在微信公众号更新！