云服务 持续交付初探

shawnyu · 发布于 2015年07月20日 · 最后由 zgm 回复于 2015年07月20日 · 1853 次阅读
703

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

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

共收到 4 条回复
2443

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

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

115

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

703

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

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