用 Docker 部署私有镜像太复杂了，大家看看怎么简化这个流程

一般是这么做吧：

1. 本地提交代码，push 到 git server （手动）
2. CI 服务制作镜像，推送到 registry （自动）
3. 本地开发环境更新（手动）

3. 可以写成一个 shell 脚本就行了吧。

另外看到你的图右边是生产环境，这样的话也可以把更新服务器放到 CI 服务器中去做。一般用 jenkins 之类的。

有实力的话就上自动化部署吧 比如 gitlab 就自带镜像库和 CI，不过我没实战过

你们公司没有 devops 运维吗？

@liubin 我是考虑脱离 Git 来做这个事情

@lfzyx 还没有

自动构建代码与打包镜像势必要用到 jenkins，要做到提交代码自动构建势必要用到 git 的 webhook 或类似功能

你不可能空手锤钉子还想要效率，不现实。

@daijinming 看来你是要全栈的节奏

@darrenfang 朋友，我对 CI 这个概念没有真实的体会，没有处理过，需要操作那些才能做到 CI,CI 是 Github 的一个功能吗

@lfzyx 俺还在尝试阶段

@daijinming #10 CI 是持续集成，目前开源解决方案有 gitlab 和 jenkins 等，还有其他商用方案，目前比较成熟的是 jenkins，使用 jenkins 可以根据 gitlab webhook 自动打包 docker、maven、apk 等。

jetbrain 家的 IDE 有 docker 插件，也许能直接达到你的目的，没有用 jetbrain 的话可以了解一下 docker-machine。

剩下的事就是写个本地 hook 脚本。

jenkins+playbook

@CivAx webhook 我大概能理解，应该是个推送开关，也就是说我的架构图中欠缺一个 jenkins,就齐活了吗

@daijinming #16 你就缺个 jenkins ,devops 工具链学习一下吧~

@sep1025 这个套路我之前也用过，你们公司应该是互联网公司吧，不是那种面向项目开发的，客户多，代码项目分散的感觉不太使用，你看那

开 ssh，让我装 jenkins，脚本就得你自己来写了，推荐 shell。通用。

@cloudbeyond 如果我这里有很多台服务器，当然每个服务器都是独立的，你觉得这个 jenkins 也能胜任吗

@daijinming CI 可以完成你操作步骤中的 2、3 （ 4、5 应该也可以，没尝试过）。

GitHub CI 可以选择 travis / circleci，推荐 circleci，可以添加私有项目，每月 1000 分钟免费构建时间。

本地 git 服务器可以使用 jenkins。

通常情况是这样：
代码提交到 Git
↓
Git 在相关项目的 Integrations 中设置 Webhook （ URL 从 Jenkins 获取
↓
Jenkins 根据 Git 触发的 Webhook 进行自动构建代码并打成镜像
↓
Jenkins 执行对应 shell 命令（通常是 docker push
↓
Jenkins ssh 到目标服务器，执行 docker run 完成更新

这是一套完整的基于容器服务的 CI/CD 流程

docker 开启 tcp 远程控制，直接远程在部署服务器上构建镜像和启动

@CivAx 行家一出手就知有没有

@godjob 有点 hack

gitlabci runner
编译镜像就在 docker 中进行
更新镜像就在本地 runner 进行，打一个 tags 即可

这个工具挺好用，https://github.com/joewalnes/websocketd，直接在远程执行 shell 脚本，在浏览器可以看见输出。

@CivAx
@daijinming
现在 GitHub actions 就可以完成前几步了：

push 到 GitHub ；
GitHub Actions 自动触发，执行自己定义的测试、构建、发布等；
GitHub Actions 触发 webhook，Jenkins 执行后续部署。

不过 Actions 还在 beta 测试阶段，可以看 https://xlui.me/t/github-ctions-beta

用 jenkines 就行啦，gitlab 拉代码打包，maven 有 docker 插件，打包的时候可以触发制作镜像上传 habor，再写个部署脚本，更新镜像，重启。

问题是,这有什么复杂的

在 CI 上 build 镜像，推到 Registy，然后 SSH 到服务器上执行服务器的部署脚本
服务器上的部署脚本差不多就是停掉现有的容器，拉取 latest 镜像，然后重启部署

gitlab ci

然而并不复杂啊。

@godjob 有 hijacked 风险。

都 2019 年了... 也该上 k8s 或者 OpenShift 了

[drone]( https://github.com/drone/drone) 用来做 CD 更好用更简单，因为本身就是 Docker based，但实际打包对机器性能有要求，0.5 内存的基本会构建内存不够用卡死了。此外阿里云的私有 Docker Registry 免费速度又快，免去自己搭建和管理服务了。

所以 serverless 会是以后的主流

把代码分开管理, 用卷挂载到 docker 里面, 就不要每次重新部署了

如果是单机部署，docker-compose + docker machine 也可以的，也就是说开发过程直接在服务器上构建镜像～

如果只是拉代码部署更新，就不需要自己写 shell 脚本了吧，给镜像添加配置文件可以解决不少问题

写 compose 啊

假设 Jenkins 主要用来打包，打包通过 Docker 的 multistage-build 替代，就不依赖 Jenkins 了，仅供参考。
Dockerfile 示例：
https://gist.github.com/dongfg/aedd3eacd33094bc594786800c99da53

daocloud 没烦恼

domeos 挺好用的

@daijinming Java 的话可以看下谷歌的 jib

@rayingecho #35 看了一会没有看懂打包镜像推送私有镜像和 k8s 有啥关系

自己的项目一个原则是能花钱的就不自己动手 ^_^， 所以我们用的 bitbucket 的 pipeline

1. 开发人员推送分支到 bitbucket
2. bitbucket 执行对应分支的 pipeline，构建 docker 镜像（用 tag 区分分支），上传到 docker hub （私有的）
3. docker compose 自动更新对应 dev，test，prod 的镜像

全程开发人员只需要推送代码；目前正在准备上 k8s

上 k8s 吧

推荐上一套 CI/CD，可以考虑用 drone ( drone.io ) docker 部署，CI 流程的每一步都是调用 docker 镜像执行，扩展非常方便，运维成本低，能很好地和 GitHub、GitLab、Bitbucket 集成。

图里的这几步除了编写代码，其他都可以自动执行。但是考虑到生产环境的问题，最后一步上线也可以配置成手动执行完前面所有步骤包括更新线上镜像，最后用一条命令确认执行预先定义好的上线流程。

本地->push(gitlab)->gitlab ci(gitlab runner)->docker push(registry Harbor)->K8s(pull)

最后在 gitlab ci 里面调用 K8s api 自动打包->自动更新

真实案例:

本地 -> gitlab MR -> gitlab CI -> commit hash 作为镜像版本号推送到叮叮 -> 通过 helm 更新 devtest 的 k8s, 验证 -> Merge 进 master -> gitlab CI -> commit hash 作为镜像版本号推送到叮叮 -> 通过 helm 更新 staging 的 k8s -> 打 tag 发版本 -> gitlab CI -> commit hash 作为镜像版本号推送到叮叮 -> 通过 helm 更新 prod 的 k8s

有现成的方案，Jenkins。

Java 的话可以看下谷歌的 jib

上 k8s 吧

提交代码是手动的，后面构建镜像是自动的，部署可手动可自动

godjob 的思路，+1。[docker-py]( https://docker-py.readthedocs.io/en/stable/ ) 了解一下。或者你把代码写完了，fabric 跑 2-5 环节可以鸭。

@joesonw hello joesonw，想问下你们通过 helm 更新 k8s 时，用的 kube_token 是怎么获取的？方便的话可以私下请教么？