drone

drone 无人机

导航

1. 背景
2. 简介
3. 注意事项
4. 使用场景

背景

先说几句闲话，docker这个概念刚出的时候，我其实已经关注到了。
大概在14年到15年时，我已经在非生产环境推行docker了，尝试将例如原来在使用 zabbix, nginx, tomcat, memcache等, 以及一些小的管理系统，还有一些工作中自己开发的python服务给容器化。

但之后几年时间反复前进后退，没有什么实质行的进展。
直到18-19年上云的大背景下，才集中一波将当时项目的生产环境的业务给容器化。

原因一直很清楚，就是上容器很简单，但是更新困难。

比如 python 程序，你发现有个字符串需要改, 原本直接 vi 编辑加 restart 即可；
现在却要提交代码，重新打镜像，上传，拉镜像，更新服务，步骤太繁琐啦。

为什么不自动化实现这些步骤呢？

原因是当时要实现这些，基本上只有两种方案，

1. 写大量shell脚本
2. jenkins

我以前写过很多 bash 脚本，几乎写吐，实在是不想写了，被里面各种特性，各种奇淫技巧，和隐藏的各种陷阱杀害了太多脑细胞。
而且很明显 bash 并不适合完成太大的流程。

然后就是 jenkins, 我从14年开始接触这个工具，直到今天我依然不喜欢，复杂+繁琐，我几乎每年都要重新学一遍，然后再忘一遍。

直到 drone 这个系统的出现，终于感觉有个好用 CI 工具的了。

drone 简介

1. go 开发，意味着部署简单
2. master+slave 结构，扩展方便
3. 容器化，全程使用 docker 完成
4. 插件支持友好

我个人认为最大的优点是 插件友好;

插件简介

1. 一个插件就是一个容器，简介
2. 插件无依赖关系，对离线环境极为友好; jenkins 的离线环境装更新插件就非常难处理依赖关系; 当然 jenkins 离线首次安装时插件可以直接拷贝进去，但后面再加就不好办了
3. 插件支持 go 开发，也支持 sh 开发
4. 无用户体系，直接使用 git 源的账户系统
5. 编排文件 .drone 采用 yml 结构，比 Jenkis 的 Jenkinsfile 文件格式友好太多

而且可以很方便的看到部署流程图

缺点

有几个不得不说的注意事项

drone 分开源版本和企业版本; 开源版本需要自己编译生成二进制文件或镜像; 官方释放出来的包其实是企业版本的;

企业版本默认是有很多限制的, 但在特定情况下是可以免费使用的;

1. 一年构建次数不超过 5000 次
2. 企业年收入低于 100 万美元, 或融资少于 500 万美元

主要就这个限制, 超出后按协议需要付费;

个人使用的话，一般一年不会超出这个次数限制;

企业使用的话，其实影响也不大, 到次数前把库删除服务重新部署一份就是， 受影响的也就 保存的一些 secret 和 构建历史记录, 这些都好重建或干脆删除；

如果对这个商用协议很敏感的话，还有2个办法

1. 通过开源版本自己编译一份
2. 使用完全开源的 woodpecker(啄木鸟) 来平替 drone

使用方式

1. 物理机方式 部署一个 server 和 一个以上 runner
2. docker-compose 方式
3. k8s 内部署方式

不同的部署方式影响一些插件的使用和 pipeline 的类型;

k8s环境使用事项

1. 因为当前 k8s 环境没有使用 docker, 所以镜像打包用的是 google 的 kaniko 工具来打包
2. 一个 pipeline 本质上就是一个 pod, 每个 step 实际上就是这个 pod 内的一个容器
3. runner 因为要创建新的 pod, 所以需要 api 权限, 这里创建了 sa, 并绑定了创建 pod 的权限;
4. 因为运行机器的不确定性, 所以编译缓存我们使用了一个 pvc 来单独放置
5. 这里有使用 drone-k8s-plugin 插件发布 yml 资源文件到集群, 所以需要还需要一个 sa 帐号