这是一个创建于 742 天前的主题，其中的信息可能已经有所发展或是发生改变。
版本迭代快的时候，docker 构建推送镜像很麻烦，下载上传整个镜像的数据很耗时间，
实际上改动的就是核心系统代码那一块，其他外部依赖没有动
所以，想把更新代码的步骤放到启动脚本里面去做，然后通过参数来设定，在 docker 启动的时候判断是否执行更新代
码的步骤，不知道这样是否可行
试了下 CMD 和 ENTRYPOINT , 在 docker run image_name -k (启动参数) 这样添加参数后，好像启动参数被固定了，
docker start 的时候不能灵活的修改，是否添加启动参数了
 |
1
shiny 2022-11-13 20:31:32 +08:00
换个思路，让外部依赖能被缓存。比如 nodejs 使用 multi-stage build 后，package.json 如果没动过，这部分就会直接缓存。
|
 |
2
beginor 2022-11-13 21:08:47 +08:00 via Android
搭 registry 私服，先推一个基础镜像上去， 比如 nodejs ，java spring ， 然后再基于基础镜像编译 app 镜像
|
 |
3
chiuan 2022-11-13 22:44:39 +08:00
程序镜像一般都不大吧。。。推送一下还能费几秒？
|
 |
4
julyclyde 2022-11-14 09:18:12 +08:00
建议参考一下“immutable”这个概念，别在容器内做运行时更新
docker image 本身是分层的。你在 build 的时候安排一下顺序，把变动的放在最上层就能减少很多浪费了 |
 |
5
palytoxin 2022-11-14 09:24:38 +08:00
之前离线部署过个 2g 的 ruby python 加一些依赖 c++库的混合镜像，镜像基本不变，部署时候把目录挂进去就行，你要多机部署就搞个 nfs
|
 |
6
ragnaroks 2022-11-14 09:31:53 +08:00
#4 说得对，你打包镜像应当最后一步才是 copy 编译产物，那么当你的业务机器有上一次的镜像时，拉取最新镜像只会拉取最终不同的那一层，基本上也就是你的编译产物的体积
|
|
7
ragnaroks 2022-11-14 09:34:09 +08:00
FROM builder
...... COPY builder/artifact /app WORKDIR /app ENTRYPOINT /app/file 一般保持 CMD 空白用于运行时提供不同的参数 |
 |
8
simonlu9 2022-11-14 09:34:50 +08:00
可以把依赖库和核心代码分离出来，比如 sprintboot 可以把 lib 不打包到镜像，只打包核心代码就可以
|
 |
10
libook 2022-11-14 11:20:59 +08:00
有些镜像比如 TTRSS 是在镜像内部的启动脚本更新代码，镜像本身就是个壳子，但每次启动都更新代码时间有点长，如果你不需要启动即可快速使用的话就可以考虑。
另外现在通常配合容器都会使用 CI 自动构建和自动部署，镜像规划好 Layer 也可以省很多时间和空间。 |
 |
11
baleeny 2022-11-14 12:19:26 +08:00
4 楼+1
|
 |
12
echooo0 OP @libook #10 所以我想的是，通过参数来指定，是否启动的时候执行更新代码的步骤。
但是 docker run image_name -k (启动参数) 这样添加参数后，启动参数好像被固定了，docker start 不能改变是否添加这个参数 |
 |
14
sdwgyzyxy 2022-11-15 08:48:00 +08:00
核心应该是编译+部署分开，例如 golang ，编译环境非常大，而项目真实运行的就是 build 之后的那个文件，很小很小。
|
 |
15
rainfd 2022-11-15 10:44:25 +08:00
容器不复杂的可以用 ko 编译构建，或者直接使用 skaffold 本地 Ci
|
Select Language