1. Dockerfile核心指令深度解析Dockerfile就像一份烹饪食谱告诉Docker如何把原材料基础镜像加工成一道美味佳肴最终镜像。我们先从最关键的几个指令开始这些指令相当于食谱中的切菜、翻炒这些基本操作。1.1 FROM你的镜像从哪里来FROM指令就像做菜时选择的基础食材它是Dockerfile的第一条指令注释除外。我见过不少新手直接使用FROM ubuntu这样的写法这其实是个隐患——因为你永远不知道下载的会是哪个版本的Ubuntu。最佳实践应该是FROM ubuntu:20.04明确指定版本号可以避免后续构建出现意外情况。我曾经遇到过一个经典案例某团队使用FROM node构建的镜像在三个月后突然构建失败原因就是默认的latest标签指向了新版Node.js而他们的代码并不兼容。对于生产环境我建议使用带哈希值的完全限定引用FROM ubuntusha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2这样能确保每次构建使用完全相同的基础镜像。1.2 RUN在构建过程中执行命令RUN指令就像烹饪时的加工步骤比如将蔬菜切丁、腌制10分钟这样的操作。但很多人不知道RUN的写法直接影响镜像层数和大小。常见错误写法RUN apt-get update RUN apt-get install -y python3 RUN rm -rf /var/lib/apt/lists/*这样会产生三个镜像层而且apt缓存仍然会保留在最终镜像中。优化后的写法RUN apt-get update \ apt-get install -y --no-install-recommends python3 \ rm -rf /var/lib/apt/lists/*这个优化实现了减少到一层镜像--no-install-recommends避免安装非必要依赖及时清理apt缓存1.3 COPY vs ADD文件复制的艺术这两个指令都用于将文件复制到镜像中但ADD功能更多也更危险。我建议99%的情况下使用COPY只在需要自动解压tar包或从URL下载文件时才用ADD。COPY的正确用法COPY requirements.txt /tmp/ COPY ./src /app/src注意第一个参数是相对于构建上下文的路径第二个是容器内的绝对路径。ADD的特殊场景ADD https://example.com/big.tar.xz /tmp/ ADD local.tar.gz /tmp/这些情况下ADD会自动解压文件但要注意从URL添加的文件不会自动解压自动解压可能带来安全隐患1.4 CMD与ENTRYPOINT容器启动行为控制这对指令经常让人困惑我用一个餐厅的比喻来解释ENTRYPOINT像是固定的主菜烹饪方式CMD则是默认的配菜典型组合ENTRYPOINT [python3] CMD [app.py]这样运行容器时docker run myimage会执行python3 app.pydocker run myimage test.py会执行python3 test.py记住几个要点ENTRYPOINT通常用于不可变的执行命令CMD提供默认参数可以被docker run覆盖使用JSON数组格式exec形式可以避免shell解析问题2. 高效镜像构建实战技巧构建Docker镜像就像搭积木方法对了事半功倍。下面这些技巧都是我踩过坑后总结的实战经验。2.1 多阶段构建精简镜像的利器这是我最推荐的镜像优化技术特别适合需要编译的应用程序。来看一个Go语言的例子# 第一阶段构建环境 FROM golang:1.20 AS builder WORKDIR /app COPY . . RUN go build -o myapp # 第二阶段运行环境 FROM alpine:3.18 WORKDIR /app COPY --frombuilder /app/myapp . CMD [./myapp]最终镜像只有十几MB而如果直接用golang:1.20作为基础镜像可能会超过1GB。多阶段构建的关键点使用AS给构建阶段命名通过COPY --from从之前阶段复制文件最终阶段只包含运行时必要组件2.2 合理利用构建缓存Docker的构建缓存可以显著加快构建速度但用不好反而会成为绊脚石。我整理了一个缓存失效规则表变更内容缓存是否失效FROM指令的基础镜像是COPY/ADD的文件内容是RUN指令的文本内容是后续指令变更是注释或空白行否缓存优化技巧把变动频率低的指令放在前面对于包管理操作先复制依赖声明文件COPY package.json yarn.lock /app/ RUN yarn install COPY . /app/这样只有当package.json或yarn.lock变化时才会重新安装依赖2.3 .dockerignore被忽视的优化点这个文件的作用类似于.gitignore但很多开发者忽略了它。我曾见过一个项目因为没使用.dockerignore导致每次构建都要上传500MB的无关文件。典型的.dockerignore内容.git node_modules *.log .DS_Store dist特别注意不要忽略Dockerfile和必要的配置文件测试文件、文档通常不需要包含在镜像中构建产物应该由构建过程生成而不是从主机复制3. 安全性与最佳实践构建镜像不仅要考虑效率安全性同样重要。下面这些实践能帮你避开常见的安全陷阱。3.1 非root用户运行容器默认情况下容器以root用户运行这存在安全隐患。正确的做法是RUN groupadd -r appuser useradd -r -g appuser appuser USER appuser进阶技巧使用固定的UID/GID便于主机权限管理对于需要特权操作的容器考虑使用--cap-add而非直接使用root3.2 镜像扫描与漏洞管理即使基础镜像也可能包含漏洞我建议定期扫描镜像docker scan image使用docker scout监控生产环境镜像关注官方镜像的安全公告3.3 环境变量与敏感信息永远不要在Dockerfile中硬编码密码或密钥正确的做法是ENV APP_PORT8080然后在运行时传入敏感信息docker run -e DB_PASSWORDsecret myimage对于复杂配置可以使用配置文件并通过卷挂载docker run -v ./config:/config myimage4. 真实项目Dockerfile剖析让我们看一个生产级Python应用的Dockerfile示例融合了前面讲的各种技巧# 构建阶段 FROM python:3.9-slim as builder WORKDIR /app ENV PYTHONDONTWRITEBYTECODE1 \ PYTHONUNBUFFERED1 RUN apt-get update \ apt-get install -y --no-install-recommends gcc python3-dev \ rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --user -r requirements.txt # 运行阶段 FROM python:3.9-slim WORKDIR /app ENV PATH/root/.local/bin:$PATH \ PYTHONDONTWRITEBYTECODE1 \ PYTHONUNBUFFERED1 # 从构建阶段复制已安装的包 COPY --frombuilder /root/.local /root/.local # 复制应用代码 COPY . . RUN useradd -m myuser \ chown -R myuser:myuser /app USER myuser EXPOSE 8000 CMD [gunicorn, --bind, 0.0.0.0:8000, app:app]这个Dockerfile的精妙之处在于使用多阶段构建分离构建环境和运行环境构建阶段安装编译依赖运行阶段保持精简设置了Python优化相关的环境变量使用非root用户运行清晰的指令排序充分利用构建缓存构建这个镜像时我通常会使用docker build -t myapp:1.0.0 --build-arg ENVproduction .记得给镜像打上有意义的标签而不是默认的latest这便于后续的版本管理和回滚。