小团队的CI&CD该如何处理

0x00 前言

最近开始自己摸一些小鱼，算是拓展一下知识面。因此开始寻找可以降低配置量的 CI 与 CD 方案。

因为我所在的团队以及我个人的业务非常非常小，机子的配置也很拉，很显然像是 Jenkins 动辄 Gb 级别的内存消耗对于我来说实在是吃不消（虽然配过一次效果还行）。（J a v a ！

鉴于目前已经尝试了两种轻量的 CI CD方式，我想是时候来写一篇总结了。

0x01 Drone 方案

最近跑出来自己摸鱼，于是抛弃了之前使用的 CD 方案，直接利用 Drone 做 CD。我个人也推荐使用 Drone，使用几行 docker 命令即可轻松部署。短期使用下来，效果非常的好。 在我的专案中使用的是 GitHub + Drone，如果你的团队有私有化部署 Gitea 也可以轻松接入 Drone，Drone 现在已经支持了不少常见平台。 小团队很显然不会有很多台机子，因此肯定需要在一个机子上配不少的服务，我在尝试 nginx 和 Caddy 后推荐使用 Caddy 作为搭在 Drone 之前的反代，自动化的 TLS 证书签发将会省去你在配置证书上花费的时间而简单的配置方式也是我推荐 Caddy 的一大原因。

我的 CD 方案主要利用了 Docker（感谢 Docker）。

项目配置思路：

1. 为程序配置能 run 的 Dockerfile
2. 使用 Drone 的 runner 生成容器镜像
3. 将 docker 映射到 runner 中，然后运行容器

事实上整个配置只需要两个配置文件

1. Dockerfile
2. .drone.yml

我举一个自己公开的项目：https://github.com/asjdf/wechat-mp-server （是一个自用的微信公众号后端框架，作为了 CI&CD 的实验品）

为了实现项目的 CI&CD，我首先配了符合我个人配置的 Dockerfile （基本通用但是多了插入一些东西，如果搬走的话删去即可）。然后确认一下没有配错，就可以开始配 .drone.yml 了。

我配 .drone.yml 的思路实际上很简单——Drone 将会在收到 GitHub 的 webhook 后自动拉取仓库文件，在我的配置中你可以看到我只不过将宿主机的 docker 丢给 Drone 的 runner，然后先构建容器，随后停止并删除旧的容器，接着用新的镜像起容器，最后删掉多余的镜像缓存（较为激进的删除，因为我云服务器的存储空间并不充裕而且我并不在意 CI 的时间）

最后就是配置一下反向代理，你可以在我 .drone.yml 的配置中看到我限制了的容器端口的访问，因此需要配置一下为服务配置一下反向代理即可。（我并不喜欢直接将容器的端口暴露给公网，况且如果不配置反代的话你也不好端口复用）

（个人强烈推荐使用 Caddy 代替 nginx（如果你使用 Caddy 只是为了建静态网站或是反代），虽然可能 Caddy 的性能以及相关资料并没有 nginx 那么全。就算有使用其他技术栈，如 php 的需求且不会配，那么还是根据上面的流程，写 Dockerfile，剩下的交给 Drone，最后去宿主机 Caddy 配一个反代即可（在 caddy 的配置文件中只需要加三行。

0x02 WebHook 方案

我所在的前团队使用的是 GitHub + OSS + WebHook 的方案，白嫖 GitHub Action 编译生成二进制文件，然后推入 OSS，之后打一个 WebHook 到服务器上，服务器上预先配置了 CD 的脚本，把二进制文件拉到服务器上并重启服务。

可能有些人会选择使用 ssh 直接连接上服务器，直接进行一个命令的执行，但显然这种操作方式并不安全，如果遇上恶意开发者+审查不严，ssh key 很可能就会被轻松偷走。而使用 OSS 中转就意味着普通开发者只能动到 OSS 中的文件，而服务器具体如何拉取可执行文件，如何重启服务就不那么可控了。

虽然这个方案只需在服务器上运行 WebHook，非常的节省资源，但是对比使用 Drone 的方案，我完全不推荐你采用。It is too raw! 大致的 CD 思路上文中已经说明，我就不展开讲了。

使用这个方案，需要一个非常阳间且有耐心的运维，因为每次有新的服务上线，运维需要配好进程守护与各项权限。当然这是在运维已经写好了较为通用 CD 脚本后，我并不确定你的团队能否能够处理这种问题。如果没有较为通用 CD 脚本——在我的前团队有通用脚本之前，为了一个CD，我需要先把可执行文件从 OSS 拉到服务器上，然后跑去配好 WebHook（文件+1），然后配好权限（+1），然后再去配好守护进程（文件+1），再去配置 Nginx（文件+1）。一圈忙活下来，可能还配得很不标准。

0x03 写在最后

事实上除了 Drone，如果你是 GitHub Action 的重度用户也可以尝试使用自建 Action Runner 的方案，思路和使用 Drone 配置差不多，不出意外的话也是可行的，如果你有更好的建议欢迎在下方留言。我可能会在建好自用的图床后回来重新补充一些细节，回见。