Dockerfile
Dockerfile
DockerFile构建镜像
首先通过一张图来了解 Docker 镜像、容器和 Dockerfile 三者之间的关系。

通过上图可以看出使用 Dockerfile 定义镜像,运行镜像启动容器。
Dockerfile 概念
Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。
镜像的定制实际上就是定制每一层所添加的配置、文件。如果我们可以把每一层修改、安装、构建、操作的命令都写入一个脚本,用这个脚本来构建、定制镜像,那么之前提及的无法重复的问题、镜像构建透明性的问题、体积的问题就都会解决。这个脚本就是 Dockerfile。
Dockerfile 是一个文本文件,其内包含了一条条的指令(Instruction),每一条指令构建一层,因此每一条指令的内容,就是描述该层应当如何构建。有了 Dockerfile,当我们需要定制自己额外的需求时,只需在 Dockerfile 上添加或者修改指令,重新生成 image 即可,省去了敲命令的麻烦。
DockerFile的指令
FROM 指定基础镜像
FROM 指令用于指定其后构建新镜像所使用的基础镜像。FROM 指令必是 Dockerfile 文件中的首条命令,启动构建流程后,Docker 将会基于该镜像构建新镜像,FROM 后的命令也会基于这个基础镜像。
FROM语法格式为:
FROM <image>
FROM <image>:<tag>
FROM <image>:<digest>通过 FROM 指定的镜像,可以是任何有效的基础镜像。FROM 有以下限制:
- FROM 必须 是 Dockerfile 中第一条非注释命令
- 在一个 Dockerfile 文件中创建多个镜像时,FROM 可以多次出现。只需在每个新命令 FROM 之前,记录提交上次的镜像 ID。
- tag 或 digest 是可选的,如果不使用这两个值时,会使用 latest 版本的基础镜像
RUN 执行命令
在镜像的构建过程中执行特定的命令,并生成一个中间镜像。
#shell格式
RUN <command>
#exec格式
RUN ["executable", "param1", "param2"]- RUN 命令将在当前 image 中执行任意合法命令并提交执行结果。命令执行提交后,就会自动执行 Dockerfile 中的下一个指令。
- 层级 RUN 指令和生成提交是符合 Docker 核心理念的做法。它允许像版本控制那样,在任意一个点,对 image 镜像进行定制化构建。
- RUN 指令创建的中间镜像会被缓存,并会在下次构建中使用。如果不想使用这些缓存镜像,可以在构建时指定 --no-cache 参数,如:docker build --no-cache。
COPY 复制文件
COPY <源路径>... <目标路径>
COPY ["<源路径1>",... "<目标路径>"]和 RUN 指令一样,也有两种格式,一种类似于命令行,一种类似于函数调用。COPY 指令将从构建上下文目录中 <源路径> 的文件/目录复制到新的一层的镜像内的<目标路径>位置。比如:
COPY package.json /usr/src/app/<源路径>可以是多个,甚至可以是通配符,其通配符规则要满足 Go 的 filepath.Match 规则,如:
COPY hom* /mydir/
COPY hom?.txt /mydir/<目标路径>可以是容器内的绝对路径,也可以是相对于工作目录的相对路径(工作目录可以用 WORKDIR 指令来指定)。目标路径不需要事先创建,如果目录不存在会在复制文件前先行创建缺失目录。
此外,还需要注意一点,使用 COPY 指令,源文件的各种元数据都会保留。比如读、写、执行权限、文件变更时间等。这个特性对于镜像定制很有用。特别是构建相关文件都在使用 Git 进行管理的时候。
ADD 更高级的复制文件
ADD 指令和 COPY 的格式和性质基本一致。
在 Docker 官方的 Dockerfile 最佳实践文档 中要求,尽可能的使用 COPY,因为 COPY 的语义很明确,就是复制文件而已,而 ADD 则包含了更复杂的功能,其行为也不一定很清晰。最适合使用 ADD 的场合,就是所提及的需要自动解压缩的场合。
另外需要注意的是,ADD 指令会令镜像构建缓存失效,从而可能会令镜像构建变得比较缓慢。
因此在 COPY 和 ADD 指令中选择的时候,可以遵循这样的原则,所有的文件复制均使用 COPY 指令,仅在需要自动解压缩的场合使用 ADD。
在构建镜像时,复制上下文中的文件到镜像内,格式:
ADD <源路径>... <目标路径>
ADD ["<源路径>",... "<目标路径>"]ENV 设置环境变量
格式有两种:
ENV <key> <value>
ENV <key1>=<value1> <key2>=<value2>...这个指令很简单,就是设置环境变量而已,无论是后面的其它指令,如 RUN,还是运行时的应用,都可以直接使用这里定义的环境变量。
ENV VERSION=1.0 DEBUG=on \
NAME="Happy Feet"这个例子中演示了如何换行,以及对含有空格的值用双引号括起来的办法,这和 Shell 下的行为是一致的。
EXPOSE
为构建的镜像设置监听端口,使容器在运行时监听。格式:
EXPOSE <port> [<port>...]EXPOSE 指令并不会让容器监听 host 的端口,如果需要,需要在 docker run 时使用 -p、-P 参数来发布容器端口到 host 的某个端口上。
VOLUME 定义匿名卷
VOLUME用于创建挂载点,即向基于所构建镜像创始的容器添加卷:
VOLUME ["/data"]一个卷可以存在于一个或多个容器的指定目录,该目录可以绕过联合文件系统,并具有以下功能:
- 卷可以容器间共享和重用
- 容器并不一定要和其它容器共享卷
- 修改卷后会立即生效
- 对卷的修改不会对镜像产生影响
- 卷会一直存在,直到没有任何容器在使用它
VOLUME 让我们可以将源代码、数据或其它内容添加到镜像中,而又不并提交到镜像中,并使我们可以多个容器间共享这些内容。
CMD容器启动命令
CMD用于指定在容器启动时所要执行的命令。CMD 有以下三种格式:
CMD ["executable","param1","param2"]
CMD ["param1","param2"]
CMD command param1 param2省略可执行文件的 exec 格式,这种写法使 CMD 中的参数当做 ENTRYPOINT 的默认参数,此时 ENTRYPOINT 也应该是 exec 格式,具体与 ENTRYPOINT 的组合使用,参考 ENTRYPOINT。
注意 与 RUN 指令的区别:RUN 在构建的时候执行,并生成一个新的镜像,CMD 在容器运行的时候执行,在构建时不进行任何操作。
ENTRYPOINT入口点
ENTRYPOINT 指定这个容器启动的时候要运行的命令,可以追加命令。
ENTRYPOINT 用于给容器配置一个可执行程序。也就是说,每次使用镜像创建容器时,通过 ENTRYPOINT 指定的程序都会被设置为默认程序。ENTRYPOINT 有以下两种形式:
ENTRYPOINT ["executable", "param1", "param2"]
ENTRYPOINT command param1 param2ENTRYPOINT 与 CMD 非常类似,不同的是通过docker run执行的命令不会覆盖 ENTRYPOINT,而docker run命令中指定的任何参数,都会被当做参数再次传递给 ENTRYPOINT。Dockerfile 中只允许有一个 ENTRYPOINT 命令,多指定时会覆盖前面的设置,而只执行最后的 ENTRYPOINT 指令。
docker run运行容器时指定的参数都会被传递给 ENTRYPOINT ,且会覆盖 CMD 命令指定的参数。如,执行docker run [image] -d时,-d 参数将被传递给入口点。
也可以通过docker run --entrypoint重写 ENTRYPOINT 入口点。如:可以像下面这样指定一个容器执行程序:
ENTRYPOINT ["/usr/bin/nginx"]USER 指定当前用户
USER 用于指定运行镜像所使用的用户:
USER daemon使用USER指定用户时,可以使用用户名、UID 或 GID,或是两者的组合。以下都是合法的指定试:
USER user
USER user:group
USER uid
USER uid:gid
USER user:gid
USER uid:group使用USER指定用户后,Dockerfile 中其后的命令 RUN、CMD、ENTRYPOINT 都将使用该用户。镜像构建完成后,通过 docker run 运行容器时,可以通过 -u 参数来覆盖所指定的用户。
WORKDIR 指定工作目录
WORKDIR用于在容器内设置一个工作目录:
WORKDIR /path/to/workdir通过WORKDIR设置工作目录后,Dockerfile 中其后的命令 RUN、CMD、ENTRYPOINT、ADD、COPY 等命令都会在该目录下执行。 如,使用WORKDIR设置工作目录:
WORKDIR /a
WORKDIR b
WORKDIR c
RUN pwd在以上示例中,pwd 最终将会在 /a/b/c 目录中执行。在使用 docker run 运行容器时,可以通过-w参数覆盖构建时所设置的工作目录。
LABEL为镜像添加元数据
LABEL用于为镜像添加元数据,元数以键值对的形式指定:
LABEL <key>=<value> <key>=<value> <key>=<value> ...使用LABEL指定元数据时,一条LABEL指定可以指定一或多条元数据,指定多条元数据时不同元数据之间通过空格分隔。推荐将所有的元数据通过一条LABEL指令指定,以免生成过多的中间镜像。 如,通过LABEL指定一些元数据:
LABEL version="1.0" description="这是一个Web服务器" by="Docker笔录"指定后可以通过docker inspect查看:
docker inspect itbilu/test
"Labels": {
"version": "1.0",
"description": "这是一个Web服务器",
"by": "Docker笔录"
},ARG构建参数
ARG用于指定传递给构建运行时的变量:
ARG <name>[=<default value>]如,通过ARG指定两个变量:
ARG site
ARG build_user=IT笔录以上我们指定了 site 和 build_user 两个变量,其中 build_user 指定了默认值。在使用 docker build 构建镜像时,可以通过 --build-arg [varname]=[value] 参数来指定或重设置这些变量的值。
docker build --build-arg site=itiblu.com -t itbilu/test .这样我们构建了 itbilu/test 镜像,其中site会被设置为 itbilu.com,由于没有指定 build_user,其值将是默认值 IT 笔录。
ONBUILD
ONBUILD用于设置镜像触发器:
ONBUILD [INSTRUCTION]当所构建的镜像被用做其它镜像的基础镜像,该镜像中的触发器将会被触发。 如,当镜像被使用时,可能需要做一些处理:
[...]
ONBUILD ADD . /app/src
ONBUILD RUN /usr/local/bin/python-build --dir /app/src
[...]STOPSIGNAL
STOPSIGNAL用于设置停止容器所要发送的系统调用信号:
STOPSIGNAL signal所使用的信号必须是内核系统调用表中的合法的值,如:SIGKILL。
SHELL指令
SHELL用于设置执行命令(shell式)所使用的的默认 shell 类型:
SHELL ["executable", "parameters"]SHELL在Windows环境下比较有用,Windows 下通常会有 cmd 和 powershell 两种 shell,可能还会有 sh。这时就可以通过 SHELL 来指定所使用的 shell 类型:
FROM microsoft/windowsservercore
# Executed as cmd /S /C echo default
RUN echo default
# Executed as cmd /S /C powershell -command Write-Host default
RUN powershell -command Write-Host default
# Executed as powershell -command Write-Host hello
SHELL ["powershell", "-command"]
RUN Write-Host hello
# Executed as cmd /S /C echo hello
SHELL ["cmd", "/S"", "/C"]
RUN echo helloDockerFile文件格式
## Dockerfile文件格式
# This dockerfile uses the ubuntu image
# VERSION 2 - EDITION 1
# Author: docker_user
# Command format: Instruction [arguments / command] ..
# 1、第一行必须指定 基础镜像信息
FROM ubuntu
# 2、维护者信息
MAINTAINER docker_user docker_user@email.com
# 3、镜像操作指令
RUN echo "deb http://archive.ubuntu.com/ubuntu/ raring main universe" >> /etc/apt/sources.list
RUN apt-get update && apt-get install -y nginx
RUN echo "\ndaemon off;" >> /etc/nginx/nginx.conf
# 4、容器启动执行指令
CMD /usr/sbin/nginxDockerfile 分为四部分:**基础镜像信息、维护者信息、镜像操作指令、容器启动执行指令**。一开始必须要指明所基于的镜像名称,接下来一般会说明维护者信息;后面则是镜像操作指令,例如 RUN 指令。每执行一条RUN 指令,镜像添加新的一层,并提交;最后是 CMD 指令,来指明运行容器时的操作命令。
DockerFile实例
[root@localhost ~]# cd /opt/
[root@localhost opt]# mkdir nginx ##创建Nginx目录
[root@localhost opt]# cd nginx/
[root@localhost nginx]# vim Dockerfile
FROM centos:7
MAINTAINER The is nginx <Gerry>
RUN yum install -y proc-devel gcc gcc-c++ zlib zlib-devel make openssl-devel wget && wget http://nginx.org/download/nginx-1.21.1.tar.gz
ADD nginx-1.21.1.tar.gz /usr/local
WORKDIR /usr/local/nginx-1.21.1/
RUN ./configure --prefix=/usr/local/nginx && make && make install
EXPOSE 80
EXPOSE 443
RUN echo "daemon off;">>/usr/local/nginx/conf/nginx.conf
WORKDIR /root/nginx
ADD run.sh /run.sh
RUN chmod 755 /run.sh
CMD ["/run.sh"]
[root@localhost nginx]# vim run.sh
#!/bin/bash
/usr/local/nginx/sbin/nginx ##开启Nginx服务
[root@localhost nginx]# mount.cifs //192.168.100.3/LNMP-C7 /mnt/ ##挂载镜像
Password for root@//192.168.100.3/LNMP-C7:
[root@localhost nginx]# cp /mnt/nginx-1.12.2.tar.gz ./ ##复制到当前目录下
[root@localhost nginx]# docker build -t nginx:new . ##创建镜像
[root@localhost nginx]# docker run -d -P nginx:new ##创建容器
228c1f5b8070d52c6f19d03159ad93a60d682a586c0b1f944dc651ee40576a3e
[root@localhost nginx]# docker ps -a ##查看容器
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
228c1f5b8070 nginx:new "/run.sh" 9 seconds ago Up 8 seconds 0.0.0.0:32770->80/tcp, 0.0.0.0:32769->443/tcp busy_booth
##用浏览器访问网页Dockerfile 最佳实践
多阶段构建
多阶段构建是减小镜像体积的核心手段,将编译环境和运行环境分离到不同的构建阶段。
# 阶段 1:编译阶段(使用完整 SDK 镜像)
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
# 先复制 csproj 文件,利用 Docker 缓存层加速依赖还原
COPY ["MyApp/MyApp.csproj", "MyApp/"]
RUN dotnet restore "MyApp/MyApp.csproj"
# 再复制全部源码并编译
COPY . .
RUN dotnet publish "MyApp/MyApp.csproj" -c Release -o /app/publish
# 阶段 2:运行阶段(使用精简运行时镜像)
FROM mcr.microsoft.com/dotnet/aspnet:8.0-alpine AS runtime
WORKDIR /app
# 只从编译阶段复制发布产物
COPY --from=build /app/publish .
# 设置非 root 用户
RUN addgroup -S app && adduser -S app -G app
USER app
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]前端项目 Dockerfile
# 阶段 1:构建前端
FROM node:20-alpine AS build
WORKDIR /app
# 利用缓存加速 npm install
COPY package.json package-lock.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
# 阶段 2:Nginx 运行
FROM nginx:1.24-alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]Java 项目 Dockerfile
# 阶段 1:Maven 编译
FROM maven:3.9-eclipse-temurin-17 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn -DskipTests clean package
# 阶段 2:JRE 运行
FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
# 设置时区和语言
RUN apk add --no-cache tzdata curl \
&& cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
&& echo "Asia/Shanghai" > /etc/timezone \
&& apk del tzdata
COPY --from=build /app/target/myapp.jar app.jar
# JVM 参数
ENV JAVA_OPTS="-Xms256m -Xmx512m -XX:+UseG1GC"
ENV TZ=Asia/Shanghai
EXPOSE 8080
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"].dockerignore 文件
.dockerignore 用于排除不需要发送到构建上下文的文件,减小构建上下文大小,加速构建。
# .dockerignore
.git
.gitignore
.github
node_modules
bin
obj
.vs
.vscode
*.md
*.log
Dockerfile
docker-compose*.yml
.dockerignore
.env
.env.*镜像优化技巧
减小镜像体积
# 1. 合并 RUN 指令(减少镜像层数)
# 不好的写法:
RUN apt-get update
RUN apt-get install -y curl
RUN apt-get clean
# 好的写法:
RUN apt-get update && apt-get install -y --no-install-recommends \
curl wget ca-certificates \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# 2. 使用 Alpine 基础镜像(体积更小)
FROM python:3.11-alpine # ~50MB
# vs
FROM python:3.11 # ~1GB
# 3. 使用 --no-install-recommends 减少不必要的包
RUN apt-get install -y --no-install-recommends nginx
# 4. 在同一层中安装和清理
RUN yum install -y gcc make \
&& make \
&& make install \
&& yum remove -y gcc make \
&& yum clean all
# 5. 多阶段构建(前面已介绍)构建缓存优化
# 利用 Docker 缓存层加速构建
# 原则:变化频率低的指令放前面,变化频率高的放后面
# 1. 先复制依赖文件(变化少)
COPY package.json package-lock.json ./
RUN npm ci
# 2. 再复制源码(变化多)
COPY . .
# 对于 .NET 项目同理
COPY ["*.csproj", "./"]
RUN dotnet restore
COPY . .
RUN dotnet build -c Release --no-restore安全最佳实践
# 1. 固定基础镜像版本(避免 latest)
FROM nginx:1.24-alpine
# 而不是 FROM nginx:latest
# 2. 使用非 root 用户运行
RUN groupadd -r appuser && useradd -r -g appuser appuser
USER appuser
# 3. 不在镜像中存储密码和密钥
# 使用环境变量或 Docker Secrets
ENV DB_PASSWORD=""
# 在运行时通过 docker run -e 传入
# 4. 设置 HEALTHCHECK
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
# 5. 使用镜像摘要而非标签(确保不可变)
# FROM nginx@sha256:abc123def456...CMD 与 ENTRYPOINT 组合使用
# 场景 1:ENTRYPOINT + CMD(推荐)
# ENTRYPOINT 定义主命令,CMD 提供默认参数
ENTRYPOINT ["python"]
CMD ["app.py"]
# docker run myimage → python app.py
# docker run myimage script.py → python script.py
# 场景 2:纯 CMD
CMD ["python", "app.py"]
# docker run myimage → python app.py
# docker run myimage bash → bash(完全覆盖)
# 场景 3: ENTRYPOINT 作为启动脚本
COPY docker-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/docker-entrypoint.sh
ENTRYPOINT ["docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]# docker-entrypoint.sh 示例
#!/bin/bash
set -e
# 等待依赖服务就绪
until nc -z $DB_HOST $DB_PORT; do
echo "等待数据库 $DB_HOST:$DB_PORT ..."
sleep 2
done
# 执行初始化(仅首次启动)
if [ ! -f /data/.initialized ]; then
echo "执行初始化..."
python manage.py migrate
touch /data/.initialized
fi
# 执行 CMD 传入的命令
exec "$@"常用构建命令
# 基础构建
docker build -t myapp:1.0 .
# 指定 Dockerfile 路径和上下文
docker build -f Dockerfile.prod -t myapp:prod .
# 构建时不使用缓存
docker build --no-cache -t myapp:1.0 .
# 查看构建历史(每层的大小和指令)
docker history myapp:1.0
docker history --no-trunc myapp:1.0
# 导出和导入镜像
docker save myapp:1.0 | gzip > myapp_1.0.tar.gz
docker load < myapp_1.0.tar.gz
# 使用 BuildKit 加速构建
DOCKER_BUILDKIT=1 docker build -t myapp:1.0 .
# 多平台构建
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:1.0 .
# 查看镜像详情
docker inspect myapp:1.0
# 查看镜像大小
docker images myapp
# 删除悬空镜像(无标签的中间镜像)
docker image prune关键知识点
- 部署类主题的核心不是“装成功”,而是“稳定运行、可排障、可回滚”。
- 同一个服务通常至少要关注版本、目录、端口、权限、数据、日志和备份。
- Linux 问题经常跨越系统层、网络层、服务层和应用层。
- 部署主题通常要同时看镜像、容器、卷、网络和宿主机资源。
项目落地视角
- 把安装步骤补成可重复执行的清单,必要时写成脚本或配置文件。
- 把配置目录、数据目录、日志目录和挂载点明确拆开。
- 上线前检查防火墙、SELinux、时区、磁盘、系统服务和健康检查。
- 固定镜像标签,记录端口、挂载目录、环境变量和自启动策略。
常见误区
- 使用 latest 或未固定版本,导致环境不可复现。
- 只验证启动成功,不验证持久化、开机自启和故障恢复。
- 遇到问题先改配置而不是先看日志和依赖链路。
- 使用 latest 导致结果不可复现。
进阶路线
- 继续补齐 systemd、性能监控、安全加固和备份恢复。
- 把单机操作升级成 Docker、Kubernetes 或 IaC 方案。
- 建立标准化运维手册,包括巡检、扩容、回滚和灾备演练。
- 继续补齐 Compose 编排、镜像瘦身、安全扫描和镜像仓库治理。
适用场景
- 当你准备把《Dockerfile》真正落到项目里时,最适合先在一个独立模块或最小样例里验证关键路径。
- 适合单机环境初始化、中间件快速搭建、测试环境验证和生产部署前准备。
- 当服务稳定性依赖端口、权限、目录、网络和系统参数时,这类主题会直接影响成败。
落地建议
- 固定版本号与镜像标签,避免“latest”带来的不可预期变化。
- 把配置、数据、日志目录拆开管理,并记录恢复步骤。
- 上线前确认端口、防火墙、SELinux、时区和磁盘空间。
排错清单
- 先查 systemctl、容器日志和应用日志,确认失败发生在哪一层。
- 检查端口占用、目录权限、挂载路径和网络连通性。
- 如果是新环境问题,优先对比与已知正常环境的差异。
复盘问题
- 如果把《Dockerfile》放进你的当前项目,最先要验证的输入、输出和失败路径分别是什么?
- 《Dockerfile》最容易在什么规模、什么边界条件下暴露问题?你会用什么指标或日志去确认?
- 相比默认实现或替代方案,采用《Dockerfile》最大的收益和代价分别是什么?
