Docker镜像构建：Dockerfile声明式构建 vs docker commit手工打包

1. 项目概述从“跑起来”到“传出去”为什么镜像打包是Docker真正的分水岭你刚学会用docker run启动一个 Nginx 容器页面能打开日志在刷心里一松——“Docker 我会了”。但第二天换台机器同事问你“这服务怎么部署”你翻出昨天的命令发现要手动装依赖、复制配置、改端口、调环境变量……三分钟变半小时半小时变两小时。最后你发过去一个带七八行docker run的文本对方照着敲还报错“找不到 config.yml”“权限被拒绝”“/app 目录不存在”。这就是没跨过 Docker 的真正门槛容器是运行时的快照而镜像是可复现、可传递、可验证的交付单元。标题里说的“将容器打包成镜像”和“使用 Dockerfile 打包镜像”表面看是两个操作路径实则代表两种工程思维——前者是救火式的手工快照docker commit后者是工业化标准的声明式构建Dockerfile。我带过的几十个团队里90% 的线上故障、协作卡点、CI/CD 失败根源都卡在这一步把 Docker 当成高级tar用而不是当作软件交付的契约。这个教程不是教你怎么敲命令而是帮你建立一套“镜像即契约”的认知体系它必须明确回答五个问题——这个镜像基于哪个操作系统和基础环境OS 层安装了哪些二进制、库、语言运行时依赖层应用代码放在哪怎么加载代码层启动前要做什么初始化入口层运行时以什么用户、什么权限、暴露什么端口安全与网络层Dockerfile 就是这份契约的法律文本每一行FROM、COPY、RUN都是不可抵赖的条款而docker commit生成的镜像就像手写一份没有公证、没有版本号、连签名都没有的便条——它可能今天能用明天就失效换个人就跑不通。后面所有内容都会围绕这两个路径的真实代价、适用边界、避坑细节展开。如果你正卡在“本地能跑上线就崩”“开发说没问题运维说缺东西”“CI 构建总失败”这类问题上这篇就是为你写的实战手册。2. 核心思路拆解手工打包 vs 声明式构建本质是两种交付哲学2.1 手工打包docker commit适合什么场景又埋下哪些雷docker commit的逻辑非常直白你在一个正在运行的容器里手动装好 Python、拷贝代码、改好配置、启动服务确认一切正常后执行docker commit -m add flask app and nginx conf -a devteam container_id my-flask-app:0.1这条命令会把当前容器的文件系统变更层diff layer打包成一个新的镜像。它确实快——5 分钟搞定适合临时调试、快速验证某个补丁、或者给测试同学发一个“能跑就行”的 demo 包。但它背后藏着三个硬伤每个都可能在关键节点让你掉链子提示docker commit生成的镜像无法追溯构建过程。你永远不知道这个镜像里到底装了几个版本的 pip、是否残留了调试用的 root 密码、有没有偷偷删掉某个关键配置文件。第一不可审计性。docker history my-flask-app:0.1只能看到一行/bin/sh -c #(nop) CMD [\python\, \app.py\]而看不到前面 20 步RUN apt-get install、COPY、sed -i是怎么一步步堆出来的。当安全扫描工具报出“该镜像含已知 OpenSSL 漏洞”你根本没法快速定位是哪次commit引入的只能重来。第二不可复现性。今天你在 Ubuntu 主机上commit明天同事在 macOS 上用相同命令拉取镜像结果发现/proc/sys/net/core/somaxconn路径在 macOS 宿主机上根本不存在导致应用启动失败。因为commit捕获的是容器运行时状态而非构建逻辑——它不保证底层 OS、内核参数、甚至 shell 版本的一致性。第三不可协作性。你提交了一个my-flask-app:0.1但没人知道这个镜像对应哪次 Git 提交、哪个分支、是否包含未 push 的本地修改。CI 流水线想自动触发构建不行因为commit没有源码关联。运维想回滚到上个稳定版只能靠你口头说“0.1 是周三下午三点打的”。我见过最典型的事故某团队用docker commit给客户交付一个数据处理服务镜像里硬编码了开发机上的绝对路径/home/dev/data/input.csv。客户部署时挂载新目录服务直接报错退出排查三天才发现是镜像里RUN cp /home/dev/data/* /app/data/这一行惹的祸——而这一行根本不在任何文档里只存在于那个被commit的容器历史中。2.2 声明式构建Dockerfile为什么它是生产环境的唯一选择Dockerfile 是一个纯文本文件用人类可读的指令描述“如何从零开始构建一个镜像”。它的核心价值不是“更高级”而是“把构建过程变成可版本化、可审查、可自动化的一等公民”。我们来看一个真实项目中简化后的 Flask 应用 Dockerfile# 1. 基础层明确指定发行版和版本号杜绝“latest”陷阱 FROM python:3.11-slim-bookworm # 2. 环境层设置工作目录、非 root 用户、时区 WORKDIR /app RUN groupadd -g 1001 -f app useradd -s /bin/bash -u 1001 -g app app ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone # 3. 依赖层分阶段安装系统依赖和 Python 包利用层缓存 COPY requirements.txt . RUN apt-get update apt-get install -y --no-install-recommends \ gcc libpq-dev rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir -r requirements.txt # 4. 代码层仅 COPY 应用代码避免误传 .git 或本地配置 COPY --chownapp:app . . # 5. 安全层切换到非 root 用户暴露必要端口 USER app EXPOSE 8000 HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 \ CMD curl -f http://localhost:8000/health || exit 1 # 6. 入口层定义启动命令支持覆盖 CMD [gunicorn, --bind, 0.0.0.0:8000, --workers, 2, app:app]这段代码的价值在于它把原本散落在终端里的 17 条命令压缩成 6 个语义清晰的段落并且每一步都可验证FROM python:3.11-slim-bookworm—— 明确锁定 Python 3.11 和 Debian Bookworm避免python:latest某天突然切到 3.12 导致兼容性问题--chownapp:app—— 在COPY时直接赋权省去后续chown命令减少镜像层数HEALTHCHECK—— 把健康检查逻辑写进镜像Kubernetes 自动注入探针无需额外配置CMD使用数组格式 —— 防止 shell 解析歧义确保信号能正确传递给主进程。更重要的是这个文件可以git add Dockerfile git commit -m add docker build support—— 和代码一起版本管理放进 CI 流水线每次git push自动触发构建并推送到私有仓库用docker build --build-arg BUILD_DATE$(date -u %Y-%m-%dT%H:%M:%SZ)注入构建时间实现镜像溯源用docker scan my-flask-app:0.1扫描漏洞报告能精准定位到apt-get install安装的libpq-dev版本。这不是“多此一举”而是把交付从“人肉搬运”升级为“机器可理解的契约”。当你开始写 Dockerfile你就不再是 Docker 的使用者而是基础设施的定义者。2.3 两种路径的决策树什么时候该用 commit什么时候必须用 Dockerfile很多初学者纠结“到底该用哪个”其实答案非常简单看交付对象和生命周期。场景推荐方式关键原因实操建议本地快速验证一个临时修改比如改一行 CSS 看效果docker commit构建耗时 10 秒无需版本管理用完立即docker rmi清理别推送到远程仓库给测试同学发一个“能跑就行”的 demodocker commit省去写 Dockerfile 时间对方只关心功能在 commit message 里写清“仅限测试勿用于生产”并附上原始容器 ID需要和 Git 代码联动、走 CI/CD 流程必须 DockerfileCI 工具无法执行交互式commit且需关联 commit hash将 Dockerfile 放在项目根目录和requirements.txt平级镜像要上生产、进 Kubernetes 集群必须 Dockerfile运维需要审计、安全团队需要扫描、SRE 需要回滚能力在 Dockerfile 开头加注释# Build from commit: abc1234CI 中自动注入构建过程涉及敏感信息如 API Key必须 Dockerfile 构建参数--build-arg可在构建时传入不留在镜像层绝对禁止RUN echo keyxxx .env应使用--secret或挂载方式我自己的经验是只要这个镜像会离开你的本地终端就必须用 Dockerfile。哪怕只是发给另一个开发同事也值得花 10 分钟写好——因为一次省下的沟通成本远大于写 Dockerfile 的时间。曾经有个项目前端同学用commit打了个 Vue 镜像发给我我本地docker run报错FATAL ERROR: Ineffective mark-compacts near heap limit。查了两小时才发现他commit前手动npm install时用了 Node 18而基础镜像是 Node 16V8 引擎不兼容。如果他用 DockerfileFROM node:16这一行就能拦住所有问题。3. 核心细节解析Dockerfile 每一行背后的原理与陷阱3.1 FROM选错基础镜像等于从悬崖边起步FROM是 Dockerfile 的第一行也是最重要的决策点。它决定了整个镜像的“地基”——操作系统、包管理器、默认 shell、甚至 libc 版本。常见错误是盲目追求“小”看到alpine镜像只有 5MB就FROM alpine:latest。但 Alpine 使用 musl libc而大多数 Python 包尤其是含 C 扩展的numpy、psycopg2默认编译依赖 glibc。结果就是pip install失败或运行时报ImportError: Error loading shared library。正确的选型逻辑是三层过滤语言生态匹配Python 项目优先选python:version-slimDebian 基础glibc预装 pipNode.js 选node:version-slimGo 项目可选golang:version-alpineGo 静态链接musl 无影响。安全与维护性拒绝latest必须锁定具体版本。python:3.11-slim比python:3.11-slim-bookworm少一层确定性——Bookworm 是 Debian 12 代号明确告诉你底层 OS 版本方便 CVE 扫描。大小与功能平衡slim镜像比full小 300MB但已包含curl、wget、tar等常用工具alpine更小但生态割裂scratch最小0MB但只能放静态编译的二进制不适合解释型语言。实测对比以 Python 3.11 为例镜像名大小libcpip 预装典型适用场景python:3.111.2GBglibc✅本地开发需要完整调试工具python:3.11-slim-bookworm180MBglibc✅生产推荐平衡大小与兼容性python:3.11-alpine3.1865MBmusl✅Go/Python 混合项目或明确支持 musl 的包python:3.11-slim-bookworm-slim120MBglibc❌需手动apt-get install python3-pip适合极致精简注意slim镜像里pip是通过python3-pip包安装的路径是/usr/bin/pip3不是/usr/local/bin/pip。如果requirements.txt里有--find-links指向私有源记得在RUN前加ENV PIP_TARGET/tmp/pip-target避免权限问题。3.2 COPY vs ADD99% 的场景只用 COPYDockerfile 里最容易被滥用的指令就是ADD。官方文档说它“比 COPY 多一个自动解压功能”但这个“多出来”的功能恰恰是安全风险的温床。ADD的三大隐患自动解压不可控ADD archive.tar.gz /app/会自动解压但解压行为取决于文件后缀不是文件头。一个伪造的.tar.gz文件实际是 zip解压就会失败或覆盖错误路径。远程 URL 下载无校验ADD https://example.com/app.jar /app/会下载并复制但不校验 SHA256中间人攻击可替换 jar 包。语义模糊ADD既可复制文件又可解压还可下载违反单一职责原则。而COPY只做一件事安全、确定地复制文件或目录。它不猜测、不解压、不联网所有输入都来自构建上下文build context可控性极强。正确用法示范# ✅ 推荐COPY 明确、安全、可预测 COPY requirements.txt . COPY --chownapp:app src/ /app/src/ COPY --frombuilder /app/dist/*.js /app/static/js/ # ❌ 避免ADD 引入不必要风险 # ADD requirements.txt . # 无意义和 COPY 一样但语义不清 # ADD app.tar.gz /app/ # 自动解压路径不可控 # ADD https://github.com/xxx.zip /tmp/ # 无校验不推荐唯一ADD的合理场景你需要在构建时下载一个已知 SHA256 的 tar 包且该包必须解压。此时应配合校验ARG TAR_URLhttps://example.com/app-v1.2.3.tar.gz ARG TAR_SHA256sha256:abc123... ADD ${TAR_URL} /tmp/app.tar.gz RUN echo ${TAR_SHA256} /tmp/app.tar.gz | sha256sum -c - \ tar -xzf /tmp/app.tar.gz -C /app \ rm /tmp/app.tar.gz但更优解是把这个下载步骤放到 CI 脚本里校验后放入构建上下文再用COPY—— 让 Dockerfile 只负责“组装”不负责“获取”。3.3 RUN如何写出高效、安全、可缓存的构建命令RUN是 Dockerfile 里最“重”的指令它会启动一个新容器执行命令并将结果保存为新层。它的效率和安全性直接决定镜像构建速度和最终体积。缓存机制Docker 的“记忆”是怎么工作的Docker 构建时会对每一层计算一个 hash基于指令内容 上一层 hash。如果某层 hash 未变就直接复用缓存跳过执行。例如RUN apt-get update apt-get install -y curl RUN pip install flask当你改了第二行pip install djangoDocker 会发现第一行RUN apt-get...的 hash 没变直接复用缓存层只执行第二行。但如果把顺序颠倒RUN pip install flask RUN apt-get update apt-get install -y curl一旦requirements.txt变更第一行RUN pip install的 hash 就变了第二行即使没改也会重新执行apt-get update—— 白花 30 秒。所以黄金法则把变化频率低的指令放前面变化频率高的放后面。典型分层系统依赖apt-get install—— 很少变放最前语言包pip install -r requirements.txt—— 中等频率放中间应用代码COPY . .—— 频繁变放最后。安全实践为什么RUN pip install必须加--no-cache-dirpip install默认会在/root/.cache/pip缓存下载的 wheel 包。这个缓存会作为镜像层的一部分被保存导致镜像体积虚增 100MB缓存里可能包含已知漏洞的旧包版本多次构建时缓存可能污染新安装pip 有时会优先用缓存而非重下载。正确写法# ✅ 强制禁用 pip 缓存减小体积提升确定性 RUN pip install --no-cache-dir -r requirements.txt # ✅ 如果需要加速用 pip 的 --find-links 指向本地 wheel 目录 # COPY wheels/ /tmp/wheels/ # RUN pip install --no-cache-dir --find-links /tmp/wheels/ --trusted-host localhost -r requirements.txt多阶段构建如何让生产镜像小一半传统构建中gcc、make、git等编译工具会留在最终镜像里既增大体积又引入安全风险CVE-2023-XXXX 可能就藏在gcc里。多阶段构建Multi-stage build用FROM ... AS builder切出一个“构建阶段”只在该阶段安装编译工具编译完把产物COPY --frombuilder到精简的运行阶段# 构建阶段安装编译工具编译前端资源 FROM node:18-slim AS frontend-builder WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction COPY . . RUN npm run build # 运行阶段只放编译好的静态文件和 Nginx FROM nginx:1.25-alpine COPY --fromfrontend-builder /app/dist/ /usr/share/nginx/html/ COPY nginx.conf /etc/nginx/conf.d/default.conf实测效果一个 Vue 项目单阶段镜像 1.2GB多阶段后仅 28MB且完全不含node、npm、gcc等任何构建工具。3.4 WORKDIR、USER、EXPOSE被严重低估的“软性规范”这三条指令不产生文件层却极大影响镜像的健壮性和可维护性。WORKDIR /app设置默认工作目录。它比RUN cd /app xxx强大得多——所有后续COPY、RUN、CMD都自动在此目录下执行且容器启动后默认进入此目录。更重要的是它让路径引用变得确定COPY config.yml .总是相对于/app不会因cd失败而错乱。USER app这是安全基石。默认容器以root运行一旦应用漏洞被利用攻击者就获得宿主机 root 权限。创建非 root 用户并切换能将危害降到最低。注意两点USER必须在COPY之后否则COPY的文件属主是 rootUSER app无法写入如果应用监听 80 端口1024需在USER前用EXPOSE 80声明但实际启动时用--cap-addNET_BIND_SERVICE或改用 8000 端口。EXPOSE 8000很多人以为它“开放端口”其实它只是文档化声明——告诉使用者“这个镜像默认监听 8000”。真正开放端口靠docker run -p 8000:8000。但它有实际价值docker ps输出中会显示0.0.0.0:8000-8000/tcp一目了然Docker Compose 里expose字段依赖它某些网络策略工具如 Istio会读取EXPOSE做流量治理。4. 实操过程从零构建一个可落地的 Flask 镜像4.1 项目结构准备最小可行的构建上下文不要把整个 Git 仓库扔进docker build。构建上下文build context是docker build命令指定的目录Docker 守护进程会把它全部打包上传。如果目录里有.git、node_modules、__pycache__不仅拖慢构建还可能意外泄露敏感信息。一个生产级 Flask 项目的推荐结构my-flask-app/ ├── Dockerfile # 构建定义 ├── requirements.txt # Python 依赖明确版本 ├── app.py # 主应用 ├── config.py # 配置不含密钥 ├── .dockerignore # 构建时排除的文件 ├── gunicorn.conf.py # Gunicorn 配置 └── README.md.dockerignore是关键防线内容必须包含.git .gitignore README.md __pycache__ *.pyc *.pyo *.pyd .Python .env .venv venv pip-log.txt .noseids .coverage .coverage.* nosetests.xml coverage.xml *.cover *.log .DS_Store提示.dockerignore语法和.gitignore完全一致。漏掉.env是高频事故——它可能含数据库密码一旦被COPY . .进镜像就永久留在层里docker history都删不掉。4.2 Dockerfile 编写逐行详解与参数说明我们写一个兼顾安全、性能、可观测性的 Flask Dockerfile# 第一部分元信息与基础层 # VERSION: 0.1.0 # AUTHOR: dev-team # DESCRIPTION: Production-ready Flask app with Gunicorn and health check FROM python:3.11-slim-bookworm # 第二部分构建参数可选用于 CI 动态注入 ARG BUILD_DATE ARG VCS_REF # 第三部分环境与用户 LABEL org.opencontainers.image.created$BUILD_DATE \ org.opencontainers.image.revision$VCS_REF \ org.opencontainers.image.version0.1.0 WORKDIR /app RUN groupadd -g 1001 -f app useradd -s /bin/bash -u 1001 -g app app ENV PYTHONDONTWRITEBYTECODE1 ENV PYTHONUNBUFFERED1 ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone # 第四部分系统依赖与 Python 包 # 更新 apt 索引安装编译依赖如 psycopg2 需要 libpq-dev RUN apt-get update apt-get install -y --no-install-recommends \ gcc libpq-dev rm -rf /var/lib/apt/lists/* # 升级 pip 到最新稳定版避免旧版 bug RUN pip install --no-cache-dir --upgrade pip # 安装 Python 依赖--no-cache-dir 禁用 pip 缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 第五部分应用代码与配置 # --chownapp:app 确保文件属主正确避免后续 USER 切换失败 COPY --chownapp:app . . # 第六部分安全加固与运行时配置 # 切换到非 root 用户 USER app # 创建运行时目录如果应用需要写日志 RUN mkdir -p /app/logs chown app:app /app/logs # 声明端口和健康检查 EXPOSE 8000 HEALTHCHECK --interval30s --timeout3s --start-period5s --retries3 \ CMD curl -f http://localhost:8000/health || exit 1 # 第七部分启动命令 CMD [gunicorn, --config, gunicorn.conf.py, app:app]关键参数说明PYTHONDONTWRITEBYTECODE1禁止生成.pyc文件减小镜像体积避免多线程时的字节码竞争问题PYTHONUNBUFFERED1强制 stdout/stderr 不缓冲日志实时输出便于docker logs查看--no-install-recommendsapt 安装时跳过推荐包避免引入无关依赖如gcc会推荐g但 Python 项目不需要--chownapp:app在COPY时直接设置属主比RUN chown少一层更高效HEALTHCHECKKubernetes 会自动识别并注入 liveness/readiness 探针无需额外配置。4.3 构建与验证三步确认镜像可用性第一步本地构建带构建参数# 获取当前 Git 提交哈希和时间戳 GIT_COMMIT$(git rev-parse HEAD) BUILD_TIME$(date -u %Y-%m-%dT%H:%M:%SZ) # 构建镜像注入元数据 docker build \ --build-arg BUILD_DATE$BUILD_TIME \ --build-arg VCS_REF$GIT_COMMIT \ -t my-flask-app:0.1.0 \ . # 查看镜像信息确认 LABEL 已注入 docker inspect my-flask-app:0.1.0 | jq .[0].Config.Labels第二步启动并测试# 启动容器映射端口后台运行 docker run -d --name flask-test -p 8000:8000 my-flask-app:0.1.0 # 等待 5 秒检查健康状态 sleep 5 docker ps --filter nameflask-test --format table {{.Names}}\t{{.Status}} # 调用健康接口 curl http://localhost:8000/health # 返回 {status: ok, timestamp: 2024-05-20T10:30:00Z} # 查看日志确认无报错 docker logs flask-test | tail -n 20第三步深度验证生产必备# 1. 检查镜像大小理想值150MB~300MB docker images my-flask-app:0.1.0 # 2. 检查镜像层应只有 5~7 层避免冗余 docker history my-flask-app:0.1.0 # 3. 扫描安全漏洞需安装 docker scan docker scan my-flask-app:0.1.0 # 4. 检查进程用户应为 app非 root docker exec flask-test ps aux | head -n 2 # 输出应类似app 1 0.0 0.1 123456 7890 ? S 10:30 0:00 gunicorn: master # 5. 模拟信号测试验证 CMD 数组格式是否正确 docker kill -s SIGUSR2 flask-test # 应触发 gunicorn 优雅重启而非容器退出4.4 推送与部署如何让镜像真正流动起来构建完成只是起点镜像需要被推送、拉取、部署。这里给出最小可行的私有仓库方案无需公网搭建本地 Registry5 分钟# 启动一个本地 registry 容器 docker run -d -p 5000:5000 --restartalways --name registry registry:2 # 给镜像打 tag指向本地 registry docker tag my-flask-app:0.1.0 localhost:5000/my-flask-app:0.1.0 # 推送到本地 registry docker push localhost:5000/my-flask-app:0.1.0 # 从另一台机器拉取需先配置 Docker daemon 信任 http registry # 在 /etc/docker/daemon.json 加 { insecure-registries:[localhost:5000] }然后 systemctl restart docker docker pull localhost:5000/my-flask-app:0.1.0生产部署检查清单项目检查方法合格标准镜像可拉取docker pull registry.example.com/my-flask-app:0.1.0成功拉取无unauthorized错误端口不冲突docker run -p 8000:8000 registry.example.com/my-flask-app:0.1.0容器启动curl localhost:8000返回 200健康检查生效docker inspect container_idjq .[0].State.Health日志可收集docker logs container_id --since 10m输出应用日志无Permission denied资源限制有效docker run --memory256m --cpus0.5 ...docker stats显示内存/CPU 在限制内5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 “pip install 失败ReadTimeoutError” —— 构建时网络问题的终极解法现象在 CI 环境或公司内网RUN pip install -r requirements.txt随机失败报ReadTimeoutError或ConnectionError。原因Docker 构建时的网络环境和宿主机不同。CI runner 可能走代理也可能 DNS 配置异常而pip默认超时仅 15 秒内网 PyPI 源响应慢就直接失败。三步解决在 Dockerfile 中全局配置 pip# 在 RUN pip install 前写入 pip 配置 RUN mkdir -p /etc/pip.conf \ echo [global] /etc/pip.conf \ echo index-url https://pypi.tuna.tsinghua.edu.cn/simple/ /etc/pip.conf \ echo trusted-host pypi.tuna.tsinghua.edu.cn /etc/pip.conf \ echo timeout 100 /etc/pip.conf \ echo retries 5 /etc/pip.conf构建时传入额外参数推荐docker build \ --build-arg PIP_INDEX_URLhttps://pypi.tuna.tsinghua.edu.cn/simple/ \ --build-arg PIP_TRUSTED_HOSTpypi.tuna.tsinghua.edu.cn \ .对应 DockerfileARG PIP_INDEX_URLhttps://pypi.org/simple/ ARG PIP_TRUSTED_HOSTpypi.org RUN pip install --no-cache-dir --index-url $PIP_INDEX_URL --trusted-host $PIP_TRUSTED_HOST -r requirements.txt终极方案离线 wheel 包在可信环境pip wheel --no-deps --wheel-dir /tmp/wheels -r requirements.txt把/tmp/wheels目录 COPY 进构建上下文再pip install --find-links /tmp/wheels --no-index。彻底断网100% 可控。5.2 “容器启动就退出no process found” —— CMD 与 ENTRYPOINT 的生死线现象docker run my-app启动后立即退出docker ps -a显示Exited (0)