自动化部署之旅 - 当我放弃了Jenkins而选择了Drone CI

简介: 一直以来对于项目的部署管理我都是采用Jenkins,但其实我使用到的也只是它接收webhook的功能,然后触发对应的项目预设shell脚本来运行部署,最近突然心血来潮,想尝试下不同的集成构建方案,在简单调研后选择了Drone,其轻量、高颜值的特点立刻吸引了我。

一直以来对于项目的部署管理我都是采用Jenkins,但其实我使用到的也只是它接收webhook的功能,然后触发对应的项目预设shell脚本来运行部署,这就显得有些杀鸡用牛刀(实际大部分公司的部署流程应该也差不多),就在最近突然心血来潮,想尝试下不同的集成构建方案,在简单调研后选择了Drone,其轻量、高颜值的特点立刻吸引了我,话不多说马上开搞,嗳~ 就是玩~

我目前的构建方案是:Github + Drone + Docker ( docker安装 )

先来看看修改前后服务器内存占用对比

使用Jenkins时:

image.png

这是停掉Jenkins,启用Drone时:

image.png

可以看到内存占用直接下降了一半,感觉轻量到可以飞起来~

体积上更是两个维度:

image.png

如果要说Drone有什么缺点的话,就是官方文档过于简单吧,有什么问题也比较难找到文章,导致折腾了不少时间。

0. 配置Github

这是使用Github作为代码托管的前置工作,首先登陆你的github账户,在右上角点击个人头像,选择Setting,选择Developer settings,选择OAuth Application,选择新建一个application:

image.png
image.png

创建成功以后,拿到Client IDClient Secret,拿小本本记下来。

  1. 这里需要注意的是 callback URL 需要填写你的Drone的登录地址,具体为drone主页链接后面加上/login

1. 安装Drone

使用docker安装drone,drone需要创建两个容器,一个提供视图界面的webService端,另一个是执行任务的runner端,这里先安装web端。

注:运行时去掉#号后面的说明

docker run \
  --volume=/var/drone:/data \ # 备注:1
  --env=DRONE_GITHUB_CLIENT_ID= \ # 备注:2
  --env=DRONE_GITHUB_CLIENT_SECRET= \ # 备注:2
  --env=DRONE_RPC_SECRET= \ # 备注:2
  --env=DRONE_SERVER_HOST= xxx.com \ #备注:3
  --env=DRONE_SERVER_PROTO=http \ #备注:4
  --env=DRONE_USER_CREATE=username:name,admin:true \ #备注:5
  --publish=10086:80 \ #备注:6
  --publish=10087:443 \ #备注:6
  --restart=always \
  --detach=true \
  --name=drone \
  drone/drone:latest
  1. drone与宿主机的目录映射,其中可将/var/drone换成你宿主机自定义的目录
  2. 填写上一步的Client IDClient Secret,RPC_SECRET和下面runner保持一致就行,为了方便我们可以直接填Client Secret,你也可以在任意终端运行openssl rand -hex 16自己生成秘钥。
  3. 你的drone域名,没有则填IP:端口
  4. 没特殊情况推荐设置http
  5. 设置admin账户(必须),将name改成你的github账户名称
  6. 映射主机的端口号(我这里占用宿主机10086端口,使用drone容器中的80端口),对外的10086端口设置为你自定义端口,记得确认已配置白名单,不是https协议可以不配443

1.1 配置nginx

贴一份nginx的配置,这里主要映射了目录到宿主机/data/nginx的位置,方便修改配置,提前配置好上一步用到的域名,如果需要的话。

  docker run -d \
  -v /data/nginx/nginx.conf:/etc/nginx/nginx.conf \
  -v /data/nginx/cert:/etc/nginx/cert \
  -v /data/docker_home:/home \
  --net host \
  --name nginx \
  nginx

2. 安装runner

docker run -d \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -e DRONE_RPC_PROTO=http \
  -e DRONE_RPC_HOST=xxx.com \ # 备注:1
  -e DRONE_RPC_SECRET=xxx \ # 备注:2
  -e DRONE_RUNNER_CAPACITY=2 \ # 备注:3
  -e DRONE_RUNNER_NAME=runner\
  -e TZ="Asia/GuangZhou" \
  -p 10088:3000 \
  --restart always \
  --name drone-runner \
  drone/drone-runner-docker:latest
  1. 填写drone域名,或IP:端口
  2. 同上一步drone容器配置的的RPC_SECRET一致,如果不是自己生成的那就是填Client Secret
  3. 最多同时执行任务数

3. 登录

打开配置好的网址,登录时会调起Github登录,登录你的Github账户即可。

image.png

点击右上角可同步你的仓库,会看到你所有的项目

点进你需要进行管理的项目(可以往github创建一个仓库测试),点击激活即可:

image.png

激活仓库之后可以进行一些配置,基本按如下即可,Trusted选项为管理员才可设置:
image.png

激活仓库时Drone会往仓库发送一条activie通知,此时对应仓库会设置进一个当前的webhook记录,不用手动去配置,非常方便。

4. 自动触发构建

接下来往测试仓库提交一条commit记录测试下

  1. 直接前往Github创建一个仓库d_test,进入Drone,点击右上角同步仓库,搜索d_test,点击Active按钮激活。
  2. d_test仓库根目录创建新文件 .drone.yml
kind: pipeline
type: docker
name: default

clone:
  disable: true

steps:
  - name: 编译步骤
    image: alpine
    commands:
      - echo hello drone

简单解释下上面的配置,首先这个文件目录与名称是可以自定义配置的,在Drone项目管理的Setting里:

image.png

配置文件注意缩进,type: docker是我们后面最主要使用的构建方式,你或许已经看出来了step里可以配置多个步骤,每个步骤都会拉取一份docker镜像使用一个临时的容器来运行,结束后立即销毁。

clone哪一行配置是将drone默认的clone步骤关闭了,由于网络问题clone仓库代码会比较耗时,后面会详细讲解实例如何自己编写一个clone操作。

  1. 回到Drone的项目管理,看到构建已经自动触发了:

image.png

image.png

而这时候这个项目也成为了活跃项目可以被筛选

image.png

至此Drone已经顺利跑起来了。

更多关于yml配置的编写在下一篇文章中会提到。

后记: 一个坑点

在Github配置Apps的时候,关注下这个地方的设置,有个token过期的机制最好退出一下,不然8小时后webhook就会失效,只能重新登录drone才会正常。

image.png

补充: 码云Gitee

drone从v2.7.2版本开始支持gitee 官网文档,部署方式和Github差不多,可以直接参考官网文档来配置,流程就是在Gitee创建第三方应用,获取Id和Key,记录下来,然后参照上面的流程即可。

如果配置Admin账户那一步不清楚用户名的话,点击码云的个人中心,看浏览器URL链接,/后面的就是你的用户名。

成功后登录时是这样的:

image.png

如果遇到仓库404问题,检查仓库名称与路径两者是否一致,采用驼峰写法它会"自作聪明"地给你把链接拆成带'-'的形式,这样drone识别仓库就会404了。

image.png

后面的就不用多说了,和Github是一样的。看了下Gitee做了个自动化推送Github的功能,可以同步两边的仓库,不过看起来以后要收费的样子,如果稳定免费的话那码云就非常业界良心了,我们也能从此摆脱Github时不时就失灵的困境,观望观望吧。

最近两天服务器连接Github直接504,我也把drone的仓库换成码云了。

相关文章
|
2月前
|
jenkins 持续交付
Jenkins自动化部署脚本
Jenkins自动化部署脚本
35 0
|
3月前
|
IDE jenkins Java
告别繁琐配置:Alibaba Cloud Toolkit插件打破Jenkins自动化部署的局限
告别繁琐配置:Alibaba Cloud Toolkit插件打破Jenkins自动化部署的局限
113 0
|
4月前
|
安全 jenkins 测试技术
自动化测试与持续集成/持续交付(CI/CD)的实践与应用
自动化测试是现代软件开发不可或缺的环节,它可以有效地提高测试效率、降低测试成本。而持续集成/持续交付(CI/CD)则是一种基于自动化的软件开发流程,能够将代码的开发、构建、测试和部署等过程无缝连接起来,从而实现快速迭代和部署。本文将结合实际案例,介绍自动化测试和CI/CD的实践与应用。
156 2
|
4月前
|
存储 测试技术 持续交付
自动化测试与持续集成/持续交付(CI/CD):优化软件开发流程的利器
自动化测试与持续集成/持续交付(CI/CD)是现代软件开发中至关重要的环节,通过将自动化测试与持续集成/持续交付相结合,可以实现开发流程的高效优化,提高软件质量和交付速度。本文将探讨自动化测试与CI/CD的概念、原理及其在软件开发中的重要性,以及如何实施这些技术以提升团队的协作效率和软件交付质量。
62 1
|
11天前
|
运维 Kubernetes 持续交付
构建高效自动化运维体系:基于容器技术的持续集成与持续部署(CI/CD)实践
【4月更文挑战第29天】 随着云计算和微服务架构的兴起,自动化运维已成为提升企业IT效率、确保系统稳定性的关键因素。本文旨在探讨如何利用容器技术构建一套高效的自动化运维体系,实现软件开发过程中的持续集成(CI)与持续部署(CD)。文章首先分析了传统运维模式面临的挑战,然后详细介绍了基于Docker和Kubernetes等容器技术的CI/CD流程设计与实施策略,并通过一个实际案例来展示该方案在提高部署频率、降低人力成本及提升系统可靠性方面的显著优势。
|
16天前
|
jenkins Java 持续交付
Jenkins与Docker的自动化CI/CD实战
Jenkins与Docker的自动化CI/CD实战
|
1月前
|
运维 Kubernetes 测试技术
构建高效自动化运维系统:基于容器技术的持续集成与持续部署(CI/CD)实践
【4月更文挑战第2天】 在快速发展的信息技术时代,自动化运维已成为提升企业IT效率、保障系统稳定性的关键手段。本文以容器技术为核心,探讨了如何构建一个高效的自动化运维系统,实现软件的持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)。通过深入分析Docker容器及Kubernetes集群管理工具的运用,提出了一套切实可行的CI/CD流程方案,旨在帮助读者理解并实践自动化运维的最佳实践,进而推动企业运维管理的现代化进程。
|
2月前
|
JavaScript jenkins 持续交付
Jenkins自动构建 CI/CD流水线学习笔记(从入门到入土,理论+示例)
Jenkins自动构建 CI/CD流水线学习笔记(从入门到入土,理论+示例)
67 0
|
4月前
|
前端开发 jenkins 持续交付
前后端分离项目知识汇总(GateWay,Nacos配置中心,Jenkins自动化部署,项目总结)-3
前后端分离项目知识汇总(GateWay,Nacos配置中心,Jenkins自动化部署,项目总结)
69 0

热门文章

最新文章