首页>软件资讯>常见问题

常见问题

Docker镜像优化

发布时间:2024-06-27 09:58:18人气:22

在当前迅速演变的软件开发行业中,Docker 以其简洁高效的容器技术,已成为编程人员和系统管理者的有力工具。但随着项目规模的增长和应用的多样化,Docker 镜像的体积问题开始变得突出,这成为了影响部署速度和成本管理的一个主要障碍。本文的目的是分享一段关于优化 Docker 镜像大小的实践经验,以帮助读者轻松地为镜像"减肥"。


在一次针对 Web 应用的 Docker 镜像优化中,我们通过优化基础镜像的方法将后端 Python 镜像大小从 464MB 减少到了 315MB,Nginx 镜像从 135MB 减少到了 13.1MB,同时保持了应用的完整性和性能。


Docker 镜像基础知识

Dockerfile 包含了一系列指令,每条指令对应镜像构建过程中的一个层级。这些指令详细定义了每层的构建方法。


Docker 镜像不是一个单一文件,而是由多个文件构成的集合,其中最关键的是层(Layers)。


在镜像构建过程中,每一层都是基于前一层构建的。一旦一层构建完成,它就会固定下来,不再改变。在后续层中进行的任何修改,如删除前一层的文件,实际上只是在这一层标记文件为删除状态,而不是真正从之前的层中移除。当容器运行时,虽然用户看不到这些被标记为删除的文件,但它们仍然作为镜像的一部分存在。


镜像的每层都可以被缓存和重用,这也是为什么从第二次构建开始,速度会显著提升的原因。利用缓存机制来优化构建速度的原理,正是基于这一特性。


如果 Dockerfile 中的指令发生变化,或者在构建镜像时使用的文件或变量有所变动,那么相应的镜像层的缓存就会失效。Docker 通过一种机制来判断文件是否发生了变化:它会获取 Dockerfile 的内容(包括文件的部分 inode 信息),并计算出一个唯一的 hash 值。如果这个 hash 值没有变化,就认为文件内容未变,可以利用缓存;如果 hash 值变化了,则认为有变动,需要重新构建。


一旦某一层的镜像缓存失效,那么它之后的所有层的缓存也会随之失效。


镜像的每一层仅记录了文件的变更。当容器启动时,Docker 会综合所有层的变更,计算并构建出一个完整的文件系统。


明白了,镜像是由多个层级构成的文件系统。为了减小镜像的体积,关键在于减少层的数量,确保每一层只包含必要的内容。在每层构建完成后,应该及时清理掉所有不必要的文件。接下来,让我们进入正题。


优化前的准备工作

在着手优化之前,我们首先对现有的 Docker 镜像进行了彻底的测试和备份。选择一个合适的基础镜像是优化的第一步,因为它直接影响到最终镜像的大小和性能。我们通过分析现有的镜像结构,确定了优化的目标和方向。


优化策略与方法

清理不必要的文件


我们通过验证程序依赖库、非必要文件拷贝等,如临时文件、编译输出等,从而减少了镜像的体积。


合并镜像层


通过采用多阶段构建的方法,我们将编译和运行阶段分离,大大减少了最终镜像的层数。此外,我们还利用了一些工具,如buildah和dockerSlim,来进一步合并和压缩镜像层。


优化基础镜像和压缩软件包和依赖


在构建过程中,我们使用了像Alpine Linux这样的轻量级基础镜像,并移除了不必要的软件包和依赖,以减少镜像体积。选择合适的基础镜像可以减小镜像大小,并确保基础镜像的安全性和更新性。Alpine、Ubuntu Minimal 等轻量级基础镜像是常用选择。


优化软件配置


我们还对容器内运行的软件进行了配置优化,关闭了不必要的服务和功能,以减少资源占用和提高安全性。


实践案例分析[使用 Alpine 版本]

这个过程中,我们遇到了一些挑战,比如如何确保多阶段构建的正确性和如何保持镜像的安全性。通过不断的测试和调整,我们最终成功地解决了这些问题。


优化前体积

优化前体积.png

优化前体积

优化前 dockerfile


FROM python:3.9.16-slim

RUN sed -i s@/deb.debian.org/@/mirrors.aliyun.com/@g /etc/apt/sources.list && set -ex \

  &&apt-get update\

  &&apt-get install gcc -y\

  &&apt-get install git curl -y

# 设定时区

#ENV TZ=Asia/Shanghai

#RUN cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

COPY backend/ /app

COPY config/ /config


# 再次切换工作目录为Django主目录

WORKDIR /app


# 安装项目所需python第三方库

# 指定setuptools的版本,必须指定,新版本有兼容问题

RUN set -ex \

    &&pip install --upgrade pip \

    &&pip install setuptools_scm -i https://mirrors.aliyun.com/pypi/simple/ \

    &&pip install  --no-cache-dir -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple/ \

    && rm -rf /var/cache/yum/* \

    && python manage.py collectstatic --noinput

EXPOSE 8001

EXPOSE 8000

EXPOSE 5555

CMD ["sh", "start.sh", "web"]

优化后体积

优化后体积.png

第一次优化后体积

优化后 dockerfile


FROM python:3.9.16-alpine3.16

RUN  apk --update add gcc g++ git curl build-base musl-dev linux-headers

COPY backend/ /app

COPY config/ /config


# 再次切换工作目录为Django主目录

WORKDIR /app


# 安装项目所需python第三方库

# 指定setuptools的版本,必须指定,新版本有兼容问题

RUN set -ex \

    &&pip install --upgrade pip \

    &&pip install setuptools_scm==7.1.0 -i https://mirrors.aliyun.com/pypi/simple/ \

    &&pip install  --no-cache-dir -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple/ \

    && rm -rf /var/cache/yum/* \

    && python manage.py collectstatic --noinput

EXPOSE 8001

EXPOSE 8000

EXPOSE 5555

CMD ["sh", "start.sh", "web"]


做了哪些工作?

本次优化过程中,我们仅仅优化了基础镜像,后端从python:3.9.16-slim 改成了 alpine 版本的python:3.9.16-alpine3.16 ,nginx 从nginx:1.20.1改成了 alpine 版本的nginx:stable-alpine3.17-slim


遇到的问题

因 linux 发行版的不一致,安装命令也做了一些调整,apt 调整成 apk

alpine 发行版的很多 linux 库是精简的,需要安装特殊适配的包

问题.png

遇到问题的解决方案

使用 apk 安装如下包apk --update add gcc g++ git curl build-base musl-dev linux-headers


优化后的测试与验证

优化完成后,我们对新的镜像进行了详尽的测试,包括功能测试、性能测试和安全测试。这些测试确保了优化后的镜像不仅体积更小,而且运行稳定,满足了生产环境的要求。



上一条:aspose-cells,一个Python中不可或缺的库

下一条:Aspose电子表格编程API