本文不是教程,重在撕逼。只是记录暴走漫画是如何实现简单持续交付方案,我们也在学习中,所以可能有很多不足,大家多多指教。
本文用一个简单的 go 项目作为示例,讲解暴走漫画如果使用 ci 和 tutum 来实现基于容器的持续交付方案。
准备工作:
一台服务器作为 ci runner(执行 ci 脚本的机器)
ci 服务器。我们用的是 gitlab-ci
代码库。gitlab
我们代码托管于自建 gitlab, 很自然的选择了 gitlab 的持续集成方案:gitlab-ci. ci 主要有两部分工作要做:1. 测试代码; 2. 部署代码
ci 所有的任务的执行者是ci-runner. 由于最初想在一台机器上实现各个项目的 runner 所以在测试部分选择的 docker 模式的 ci-runner(其他还有 shell 之类). 安装完如图:
另外由于这个项目是封装在 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.
tutum 提供了基于 docker 的一整套应用管理方案。他将应用定义为包含多种 service 的 stack, 这个 stack 的感念我感觉就是 docker-compose 而且 api 也很像。所以他的 dashboard 可以分为 stack,service,node,repository 的管理。我就不安利了,大家自己看把。
应用的载体。
点 lunch 就可以开始生成 service 并且部署。
我没有使用 stack 是因为这个项目只有一个 web server 需要单独跑,数据库之类的都是在第三方服务。
这边 tutum 默认是动态端口,可以方便的 scale. 使用了 weave 的网络方案.
不过我这目前就一个 node 就写死了。如果动态端口的话需要配合 stack 使用。
再回到之前的 tutum service xx redeploy
, 这个是 tutum 提供的命令行工具,非常方便。感觉就像在 docker-compose 外面套了一层。api 基本相似。
至此,我们已经实现了自动测试部署的功能。整个 workflow 可以通过 slack 监控
tutum 毕竟是国外的东西。折腾环境绝笔是最痛苦的!不过装好之后,感觉确实好用。有一点,tutum 分配 node 的方式只有两种:most_empitest, high_avaliable, 我不需要管到底分配给那个 node. 对这个心里总是有点点担心,不过另一边又觉得挺爽。
上面那么多其实挺简单的,没啥技术含量都是配置。下面我还会研究 tutum 的 stack, 主要是用官方的 haproxy 镜像来 scale web service.
另外还有一个需要考虑的是线上代码的快速回滚。官方提供了一篇相关的博文不过目前还没搞明白。
再发一个官方教程,蛮有帮助的:https://support.tutum.co/support/solutions/folders/5000204714