docker 如何更便捷的更新容器

[echooo0]

版本迭代快的时候，docker 构建推送镜像很麻烦，下载上传整个镜像的数据很耗时间，

实际上改动的就是核心系统代码那一块，其他外部依赖没有动

所以，想把更新代码的步骤放到启动脚本里面去做，然后通过参数来设定，在 docker 启动的时候判断是否执行更新代

码的步骤，不知道这样是否可行

试了下 CMD 和 ENTRYPOINT , 在 docker run image_name -k (启动参数) 这样添加参数后，好像启动参数被固定了，

docker start 的时候不能灵活的修改，是否添加启动参数了

[shiny]

换个思路，让外部依赖能被缓存。比如 nodejs 使用 multi-stage build 后，package.json 如果没动过，这部分就会直接缓存。

[beginor]

搭 registry 私服，先推一个基础镜像上去， 比如 nodejs ，java spring ， 然后再基于基础镜像编译 app 镜像

[chiuan]

程序镜像一般都不大吧。。。推送一下还能费几秒？

[julyclyde]

建议参考一下“immutable”这个概念，别在容器内做运行时更新

docker image 本身是分层的。你在 build 的时候安排一下顺序，把变动的放在最上层就能减少很多浪费了

[palytoxin]

之前离线部署过个 2g 的 ruby python 加一些依赖 c++库的混合镜像，镜像基本不变，部署时候把目录挂进去就行，你要多机部署就搞个 nfs

[ragnaroks]

#4 说得对，你打包镜像应当最后一步才是 copy 编译产物，那么当你的业务机器有上一次的镜像时，拉取最新镜像只会拉取最终不同的那一层，基本上也就是你的编译产物的体积

[ragnaroks]

FROM builder
......
COPY builder/artifact /app
WORKDIR /app
ENTRYPOINT /app/file

一般保持 CMD 空白用于运行时提供不同的参数

[simonlu9]

可以把依赖库和核心代码分离出来，比如 sprintboot 可以把 lib 不打包到镜像，只打包核心代码就可以

[Latin]

@julyclyde 针对需要依赖安装类的镜像 COPY 应放置最下层

[libook]

有些镜像比如 TTRSS 是在镜像内部的启动脚本更新代码，镜像本身就是个壳子，但每次启动都更新代码时间有点长，如果你不需要启动即可快速使用的话就可以考虑。

另外现在通常配合容器都会使用 CI 自动构建和自动部署，镜像规划好 Layer 也可以省很多时间和空间。

[baleeny]

4 楼+1

[echooo0]

@libook #10 所以我想的是，通过参数来指定，是否启动的时候执行更新代码的步骤。

但是 docker run image_name -k (启动参数) 这样添加参数后，启动参数好像被固定了，docker start 不能改变是否添加这个参数

[julyclyde]

@echooo0 是啊，你的程序应该适应无监管启动的场景

[sdwgyzyxy]

核心应该是编译+部署分开，例如 golang ，编译环境非常大，而项目真实运行的就是 build 之后的那个文件，很小很小。

[rainfd]

容器不复杂的可以用 ko 编译构建，或者直接使用 skaffold 本地 Ci