用 doker 发布程序的正确打开方式

[wellhome]

下面两种，哪个正确。

1. 每次发布用 DockerFile 打包一份新 image
然后把 image tag latest 发布

2. 在上次打包的 image 基础上 运行 docker commit，产生一个最新 image 。

目前我用方法 1 。每个 image 都是独立的 commit，之间是没父子关系。
我的疑惑是，docker commit 这个机制是不是可以淘汰了。

[wellhome]

@fannas 1 2 3 层 每次在发布 code 的时候 ，都用 DockerFile 从头打包？

[jinliming2]

@fannas 配置 config 不应该设置为运行时从环境变量里读吗？或者设置为 mount point 在运行时指定导入进去？

[chenqh]

有一个问题，docker 怎么用起来比较好，单机 docker registry 有点浪费呀

[jinliming2]

@wellhome Dockerfile 只有第一次会从头打包，后续发布更新都不会从头打包，只会从变化的位置开始打包，之前没有变化的 Dockerfile 语句都会复用。比如：

FROM xxxxxx # 这一句每次都一样，直接复用
RUN apt-get update && apt install -y xxx # 这一句也是每次都一样，直接复用
COPY . . # 这一句开始，因为拷入的代码文件变了，所以从这一行开始后面的全部重新构建
RUN build ... # 从上一句开始从新构建

所以一般来说，安装依赖之类的语句尽可能提前，这样后续打包的时候就不会重新构建了。

实际上你可以简单理解成你的 Dockerfile 里每一条语句都是一个 commit （不正确，部分语句是会合并的），相互之间就是父子关系。具体表现在你 docker pull / push 的时候显示的那个进度条的个数。你每次构建的时候，如果这条语句前面的环境都是一样的话，并且当前这一层没有任何变化的话，那么这一条语句就不会重新执行，而是直接复用之前的构建结果。这样一来你会发现，在重新 docker push 的时候，会提示你部分层已经在服务器上存在了，只会 push 变动的部分。

[wellhome]

@jinliming2 "RUN apt-get update && apt install -y xxx # 这一句也是每次都一样，直接复用", 复用的前提是你本地已经有 cache， 我们的的 ci/cd 的 agent 是随机分配的。如果进行发布的 agent 上以前没有打过包，也就是说没有 cache， 那么应该还是从头开始一层一层打， 没有复用。

[SmiteChow]

docker commit 用于复用他人的镜像场景。当你不知道或不关心镜像 Dockerfile 怎么写的，但你又想复用镜像的时候，commit 能快速生成包含你修改的新镜像。

[dier]

基于你们项目运行的环境打一个基础镜像，例如（系统--软件--环境变量），然后每次发新代码时，在 Dockerfile 中 FROM 这个基础镜像来构建一个最新代码的镜像，发布的时候就发布最新的镜像。有基础镜像就可以提交镜像构建的速度，不需要次都去安装各种软件，特别是每次的 agent 不在同一台机器上没法利用之前的 cache 的环境。

[ku360517703]

方案 1 和打包镜像然后-v 挂载 jar 包进去运行，应该选哪种呢？

[fannas]

@wellhome 取决于实际情况。对于基础开发，例如 jvm python 我通常情况下使用 jre base 和 python base，在这个上加 dependency config 和 code 。没必要自己建立。如果有特殊需要就需要从头搞了。只是个人情况哈。

[fannas]

@jinliming2 config 可能用的不准确。在 jvm 软件开发的时候，resource 里面的文件通常是静态的，不进行修改的。如果这是一个离线文档 parser 或者是个生产上的预测模型，可能存在该文件夹大小几十兆甚至更大。
这种情况下先将其放入 image，最大化的减小构建 image 的大小，有利于快速分发部署。