把 docker 镜像存放在服务器上，需要的时候 pull 下来，感觉这个不算强需求啊，为什么不直接用 dockerfile 构建呢
qq5745965425 2016-06-16 00:59:09 +08:00 2913 次点击这是一个创建于 3421 天前的主题，其中的信息可能已经有所发展或是发生改变。
把 docker 镜像存放在服务器上， 需要的时候 pull 下来，
感觉这个不算强需求啊，
为什么不直接用 dockerfile 构建呢
而是要去下载呢， 只下载 dockerfile ，本地构建的话， 不是更加方便吗，而且下载的时候也很节省时间，一秒钟就可以把 dockerfile 下载到本地，然后构建就可以运行了
为什么要上传几百兆的镜像到服务器去呢
由阿里云 [容器 Hub 服务] 而想到的
https://dev.aliyun.com 就是这个，我有些想不通
我不是打广告的
10 条回复 2016-06-16 11:13:41 +08:00
 | 1 YUX PRO Dockerfile 第一行不也是 FROM 啥啥啥么 拿 Dockerfile 本地构建也要先拉下来 |
 | 2 binux 2016-06-16 01:20:02 +08:00 构建不能保证环境一致，比如 RUN 的时候依赖版本升级了。 |
 | 3 Nexvar 2016-06-16 02:48:09 +08:00 via Android image 总是要拉下来的 |
 | 4 yaodong 2016-06-16 03:16:53 +08:00 保证环境一致，并且节省时间。 我有一个 image ，做科学计算的，本地构建需要 2 小时编译。我需要在 AWS 上使用 spot instance 来组建简易的计算节点，一旦 spot instance 被踢，程序需要立刻去启动新的节点。 这样， pull 下来节约了大量的时间和一些 AWS 费用。 |
 | 5 lightening 2016-06-16 04:29:54 +08:00 pull 下来不一定是最适合你的。如果你的实际应用场景现场 build 没问题的话你完全可以这样用。 pull 整个 image 可能有一些好处：保证环境一致性；一个 image 需要部署多次的话节省时间； build 的时候占用服务器资源过大所以用专门的 build 服务 build 。 另外你也不是真的上传几百兆，只是上传改变过的 layer 而已。另外我相信你的 docker image 里的几百兆不是随机生成的，一般要么要是下载的要么是自己编译出来的。下载的话同样是下载，为什么不下载已经构建好的 image ？自己编译很耗 CPU 。 |
 | 6 matsuijurina 2016-06-16 08:07:08 +08:00 via iPhone 墙内才有的苦恼吧， pull 几百兆的镜像速度还比不上本地编译。 |
 | 7 qqmishi 2016-06-16 09:08:55 +08:00 via Android 1.网络加速，不挂代理有时候真的 pull |
| 8 qqmishi 2016-06-16 09:14:56 +08:00 via Android 智障点发送了，，， 1.网络加速，不挂代理有时候真的 pull 不下来 2.省时间，如果和源镜像相比修改较大的话，装依赖和编译还是会消耗不少时间的，尤其是那种需求特殊需要使用特有软件的 3.Dockerfile 只是描述了构建过程而已，，，该 pull 镜像还是 pull 镜像，一秒下载完 pull 不下来镜像一样没用 |
 | 9 walkman660 2016-06-16 10:47:27 +08:00  1 让我想起了以前一个技术领导是这么描述 DOCKER 优势的 开发机器用 docker 跑起来程序没问题的话，只需要拷十几 k 代码到另外一台有 docker 的机器上就能把原来的程序跑起来 233 |
 | 10 fcicq 2016-06-16 11:13:41 +08:00 1 Joyent 的路线就很接近于楼主的想法. 把自己所需要的东西打成包, 并用包管理器安装是正解, 顺便依赖关系, 签名认证等都解决了. 写 dockerfile 肯定是下策, docker 里模板基本也是带包管理器的系统, 如果构建命令只是用来装 repo 里有的东西, docker image 就和包的内容是冗余的, 用任何方法重建都非常快. 新编译没有的东西会落入验证源码完整性, 编译环境安全性, 还有事后签名的大坑. 从安全角度上用公开的模板就再糟糕不过了. linux kernel 的安全性是另一个减分点. 封装复杂构建的系统肯定是 ZFS snapshot 更好. |
Select Language