云服务 持续交付初探

shawnyu · 2015年07月20日 · 最后由 zgm 回复于 2015年07月20日 · 3366 次阅读

本文不是教程,重在撕逼。只是记录暴走漫画是如何实现简单持续交付方案,我们也在学习中,所以可能有很多不足,大家多多指教。

0x0 简介

本文用一个简单的 go 项目作为示例,讲解暴走漫画如果使用 ci 和 tutum 来实现基于容器的持续交付方案。

准备工作:

  • 一台服务器作为 ci runner(执行 ci 脚本的机器)

  • ci 服务器。我们用的是 gitlab-ci

  • 代码库。gitlab

0x1 ci 配置

我们代码托管于自建 gitlab, 很自然的选择了 gitlab 的持续集成方案:gitlab-ci. ci 主要有两部分工作要做:1. 测试代码; 2. 部署代码

ci 所有的任务的执行者是ci-runner. 由于最初想在一台机器上实现各个项目的 runner 所以在测试部分选择的 docker 模式的 ci-runner(其他还有 shell 之类). 安装完如图:

安装完ci-runner

另外由于这个项目是封装在 docker 镜像中,部署之前需要重制镜像并且更新 registry. 所以无奈又新建了一个 runner 直接跑在这个 ci 服务器上,这次使用的是linux mode. 安装完之后我们的 ci 服务器就注册两个 ci runner:

至此 ci 部分环境搭建基本结束。下面主要是在 ci 中配置相关 job.

测试 job

关键是里面的 tags. tags 决定了这个 job 的执行 runer. 在 runner 的配置中也可以指定 tag, 跟这里的 tags 是对应的,只有拥有相同 tag 的 runner 才能执行该 job.

部署 job

deploy job 里面有一个选项是 Refs, 这个可以配置你的部署分支。代码提交到指定分支之后会先做 test 通过之后就会执行 deoloy job.

类似这样

最后一句调用 tutum 的 api 重新部署 service.

0x2 tutum 配置

tutum 提供了基于 docker 的一整套应用管理方案。他将应用定义为包含多种 service 的 stack, 这个 stack 的感念我感觉就是 docker-compose 而且 api 也很像。所以他的 dashboard 可以分为 stack,service,node,repository 的管理。我就不安利了,大家自己看把。

添加 node

应用的载体。

添加私有 repository

点 lunch 就可以开始生成 service 并且部署。

配置 service

我没有使用 stack 是因为这个项目只有一个 web server 需要单独跑,数据库之类的都是在第三方服务。

这边 tutum 默认是动态端口,可以方便的 scale. 使用了 weave 的网络方案.

不过我这目前就一个 node 就写死了。如果动态端口的话需要配合 stack 使用。

再回到之前的 tutum service xx redeploy, 这个是 tutum 提供的命令行工具,非常方便。感觉就像在 docker-compose 外面套了一层。api 基本相似。

至此,我们已经实现了自动测试部署的功能。整个 workflow 可以通过 slack 监控

0x3 总结

tutum 毕竟是国外的东西。折腾环境绝笔是最痛苦的!不过装好之后,感觉确实好用。有一点,tutum 分配 node 的方式只有两种:most_empitest, high_avaliable, 我不需要管到底分配给那个 node. 对这个心里总是有点点担心,不过另一边又觉得挺爽。

上面那么多其实挺简单的,没啥技术含量都是配置。下面我还会研究 tutum 的 stack, 主要是用官方的 haproxy 镜像来 scale web service.

另外还有一个需要考虑的是线上代码的快速回滚。官方提供了一篇相关的博文不过目前还没搞明白。

再发一个官方教程,蛮有帮助的:https://support.tutum.co/support/solutions/folders/5000204714

@shawnyu 有用~ 真实案例很有用~

我有个额外的问题,选择使用 gitlab 而非 private 的 github 是出于什么目的呢?代码安全还是?

#1 楼 @wppurking 免费啊,速度啊,可制订啊。

#1 楼 @wppurking 主要是成本考虑

需要 登录 后方可回复, 如果你还没有账号请 注册新账号