docker 持续交付的疑问

[51300520]

本人新手，上次在这里提问后好不容易按老板要求把项目都用 docker 重新部署到阿里云了，现在对持续交付有新的疑问。

通常方式是代码更新并上传到 github 上后，是阿里云上的 docker 容器自己去 github 拉新代码下来还是用新代码重新做一个镜像发布出去阿里云那边直接拉新的镜像重新运行？

你们平时是 本地写 dockerfile->build 镜像->上传到 dockerhub->服务器从 dockerhub 更新这种流程。 还是直接在目标机器上 获取 dockerfile->build 镜像这种方式

[lynskylate]

本地 build 效率过低，而且损失了 docker 的意义。一般 git 提交 release 版本，触发集成，编译机出 docker 镜像，上传至私有 registry，然后目标机器拉。如果目标机器很多的话，大量的拉会影响网络的速度，可以用 p2p 的方式来加速，当然一般的公司其实不用担心。

[whileFalse]

不能在生产环境的各台机器上分别构建部署到本机。如果你有多台生产环境的机器，其中一些构建成功，一些失败怎么办？
必须要首先构建新代码并推入镜像仓库。你可以在本地构建，也可以在云中构建。如果本地下载带宽够大，未必会慢。

[whileFalse]

哦我说的本地构建是指你的持续集成系统放在本地，而不是直接在你本机上面手动构见。

[jacketma]

docker 对于很多动态语言项目，频繁更新，多了一次静态化的过程，不能实时，不如直接 push 代码来的效率高。

如果不在意损失一点机器性能的话，不用 docker 更方便，除非项目大到要考虑灰度发布，k8s 集群很大的规模另说。小微项目没必要 docker。

[anmie]

我的理解：docker 和持续集成是两套完全不同的东西。在 docker 之前持续集成就有了成熟的解决方案；
其中：持续集成指的是本地 push 代码，触发持续集成服务进行代码拉去并打包构建的过程； docker 则是拿到了构建结果之后 运行目标程序 /启服务的过程；
所以如果这样理解的话，那么比较适合的方案是云服务平台上分别有持续集成和 docker，本地只负责编码和 push 代码；

[jakehu]

本地->gitlab->gitlab runner->harbor->swarm/K8s

[ebingtel]

同意 ls …… docker 不就为了“一次 build ”么……不然，还得说“我本地是 ok 的呀”

[gouchaoer2]

你在目标机器上 build 的话好处是不消耗流量，速度较慢，如果发生了问题要回滚版本如果你没有处理就没办法很快回滚

现在持续交付 k8s 的方案已经非常成熟了吧，试试这个？

[donnior]

楼主你差一个 CI

[artandlol]

傻瓜化 web 用 rancher

[artandlol]

@lynskylate uber 最近开源一个使用 p2p

[agoodob]

我在做一个小项目，用了 Docker Swarm + CI/CD 工具。
目前流程如下（简化版）：
-> 写代码之后推到 Github
-> Github 会触发 Buddy
-> Buddy 负责 build docker image
-> Buddy 负责把镜像推到阿里云镜像仓库深圳区
-> Buddy ssh 到机器上进行 docker stack deploy
（自建 Buddy 是 30 天免费试用，我用的是 300 美金的 Google Cloud Platform 试用）
（ Buddy 官方免费版是 120 execution/month)

配 3 篇我写的文章：
Buddy 自建企业版的使用体验
https://1c7.me/buddy-on-premises/
蛋疼的 CI/CD
https://1c7.me/ci-cd/
Docker Swarm 教程-第 1 部分: 介绍
https://1c7.me/docker-swarm-part1/