写在前边
这一篇文章是基于 Gitea+Drone CI+Vault 打造属于自己的CI/CD工作流系列文章第三篇,让我们一起来完成 drone
与 gitea
的搭配使用,这篇内容比较简单和容易,也是最终篇。
在第一篇文章中(一) Drone CI For Github —— 打造自己的CI/CD工作流,我们一起了解了Drone For Github
的部署和使用,一起感受了 Drone
的简单强大的功能带来的方便和快捷。
在第二篇文章中(二) Drone CI使用Vault作为凭据存储 —— 打造自己的CI/CD工作流,我们一起了解了Vault
的部署和使用,并了解和学习了怎么为 Drone
指定 Secret
的存储为 Vault
,解决了在实际的应用中,不同项目的敏感数据重复使用以及权限控制问题。
在更早的一篇文章中基于Gitea打造一个属于你自己的代码托管平台,我们一起了解了 Gitea
的部署和使用,感受 Gitea
作为一个轻量化的代码托管平台,依然拥有丰富的功能和美观的界面。
我们分别了解了 Drone
、Vault
和 Gitea
的部署和使用,那么我们为什么不把它们结合起来,打造一个专属于自己的CI/CD工作流呢?
废话少说,说干就干,开始搞事。
组合Drone
、Vault
和 Gitea
接来下,我们开始将
Drone
、Vault
和Gitea
组合到一起,构建一个专属于自己的CI/CD工作流如果你对它们还不了解,请参考我之前的文章。
编写 docker-compose.yml
这里我们结合之前三篇文章的docker-compose.yml
加入
gitea
之后,只需要修改drone-server
的environment
删除
DRONE_GITHUB_SERVER
DRONE_GITHUB_CLIENT_ID
DRONE_GITHUB_CLIENT_SECRET
加入
DRONE_GITEA_SKIP_VERIFY
DRONE_GITEA_SERVER
1 | version: "3.7" |
结束了?
是的结束了,如果你仔细看了前两篇文章的话,会明白,这一点都不奇怪,从
github
切换到gitea
只需要简单改动配置即可。本系列前两篇文章是重中之重,请着重阅读。
总结
本篇文章简单归简单,但是整体的配合还是有一些需要注意的点需要说明一下
gitea
的账号就是用来登陆drone
的账号,在drone-server
中的environment
:DRONE_USER_CREATE
指明管理员的用户名- 所有的url都要写上协议
Vault
初始化生成的五个unseal key
和root token
一定要记住并且不能泄露drone-agent
可以有多个,做分布式。vault
也是可以分布式的
系列文章
- 基于 Gitea+Drone CI+Vault 打造属于自己的CI/CD工作流
- (一) Drone CI For Github —— 打造自己的CI/CD工作流
- (二) Drone CI使用Vault作为凭据存储 —— 打造自己的CI/CD工作流
- (三) 轻量化自建 Drone CI For Gitea —— 打造自己的CI/CD工作流
- 番外:基于Gitea打造一个属于你自己的代码托管平台
有什么问题,欢迎评论或邮件。
好了,继续划水去了。