使用Drone+gitea配置自己的CICD流程

什么是CI CD

CI CD一般包含三个概念：持续集成（Continuous Integration ，CI），持续交付（Continuous Delivery），持续部署（Continuous Deploy）。他是一种软件开发实践，核心是通过引入自动化的手段来提高软件交付效率。其最终目的是为了让工程师更快，更高质量，更简单的交付软件。

持续集成

在传统软件开发过程中，集成通常发生在每个人都完成了各自的工作之后，所谓集成，可以理解为团队里的大家完成自己负责的模块后，将各个子模块集成为一个可以完成整体功能的完整模块。在项目尾声阶段，通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式，让构建、测试和集成代码更经常反复地发生。

为了实现持续集成，我们每个人都要单元测试（unit test），保证各个子模块的正常工作。

持续交付

持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。我们把代码部署到测试环境，预发布环境等等类生产环境成为交付。

持续部署

如果真的想获得持续交付的好处，应该尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障。于是有了持续部署。

我们通常将这个在不同环境发布和测试的过程叫做部署流水线。

持续部署是在持续交付的基础上，把部署到生产环境的过程自动化。

Gitea

gitea是一款开源，由Golang编写的可自运营的代码管理仓库，相对来说gitlab功能最为全面且内置CI，但是其对内存与cpu的开销更大，而gitea更为轻量化，日常运行占用的内存仅仅只有200mb上下，对于个人开发者来自己的云服务器往往只有2核4G甚至1核1G的配置，那么性能开销就显得弥足珍贵。

Drone

drone是一款开源的持续集成核持续交付平台，他可以帮助开发者自动化构建，测试核部署应用程序，drone的核心特点就是轻量级，他使用docker容器来运行构建核测试任务，这使得它可以快速的启动和销毁环境，从而提高了效率和可靠性，drone的部署十分简单，可以通过docker轻松部署，同时drone提供可视化的web界面和cli工具，方便用户管理和监控构建任务的状态和结果。

开始部署

我使用的系统是ubuntu22.04，采用的docker部署。

这里我们均使用docker-compose来部署，不知道什么是docker-compose的同学可以先去了解一下docker及docker-compose。

Docker Compose是一个用于定义和运行多个Docker容器的工具。它使用YAML文件来配置应用程序的服务，并可以在单个命令中启动、停止和重建所有服务。Docker Compose可以帮助开发人员和运维人员更轻松地管理多个Docker容器，并提供了一种简单的方法来定义和管理应用程序的依赖关系。

Gitea docker-compose

version: "3"

services:
  server:
    image: gitea/gitea:1.19.0
    container_name: gitea
    restart: always
    volumes:
      - ./data:/var/lib/gitea
      - ./config:/etc/gitea
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000"
      - "2222:2222"
~

编辑成docker-compose.yml文件输入docker compse up -d命令，docker就会根据编排好的文件自动创建容器及映射数据卷

这里我使用的端口是3000，gitea的默认端口也是3000，访问对应地址

这里需要我们进行一些默认配置，这里我选择使用sqlite数据，这样避免了还需要部署一个数据库容器，其他的我们使用默认配置即可。

部署成功后的默认界面如图，点击右上角登录，第一个注册的账号就是管理员账号

我们注册完第一个账号即管理员账号后，接下来我们注册一个Drone专用的账号，当然你也可以就把管理员账号给Drone来用。

点击右上角用户头像->设置->应用进入如下界面

应用名称为自定义的OAuth2授权名称，可随便取。

重定向URL十分重要，必须为接下来要部署的drone server的网站地址，如果不是域名的话还需带上端口，且以/login结尾

点击创建应用后保存生成的客户端ID及客户端密钥，待会创建drone server时要使用

Drone docker-compose

Drone分为drone server和drone runner两部分

drone server

version: "3"

services:
  drone:
    image: drone/drone:2
    container_name: drone
    environment:
      - DRONE_GITEA_SERVER=http://110.41.160.73:3000
      - DRONE_GITEA_CLIENT_ID=9c77ba3c-9d13-49ae-a7a5-cfbd6a7993c2
      - DRONE_GITEA_CLIENT_SECRET=gto_zbxh6gznvbsrpskwf25ti4r7iltfe2ysjkl75hjst6dfcyuxl4oa
      - DRONE_RPC_SECRET=as103208900
      - DRONE_SERVER_HOST=110.41.160.73:3001
      - DRONE_SERVER_PROTO=http
      - DRONE_USER_CREATE=username:drone,admin:true
    restart: always
    volumes:
      - ./drone:/data
    ports:
      - 3001:80

DRONE_GITEA_SERVER：你的gitea服务器地址

DRONE_GITEA_CLIENT_ID：你创建的OAtuh2授权的客户端ID，即是上一步中要求保存的客户端ID

DRONE_GITEA_CLINIE_SECRET：你创建的OAtuh2授权的客户端密钥，即是上一步中要求保存的客户端密钥

DRONE_RPC_SECRET：drone server与drone runner通信设定的密码，可自由设置，在接下来的drone runner的docker compose中也有这个参数，必须与此处相同

DRONE_SERVER_HOST：你设置的drone server地址，可以是域名，如果不是的话则必须是带端口的ip地址，且此处设置的端口必须与

DRONE_SERVE_PROTO：设置服务器的协议，如http或https

DRONE_USER_CREATE：指定某个用户为管理员，管理员有权管理其他账户，编辑仓库详细信息，编辑仓库信任标志，访问受限制的API。注意，此处设置的username：drone，其名称就是你给drone准备的gitea的账户名称，最好是把这个账号指定为管理员，否则非管理员无法设置某个仓库为受信任仓库，而非受信任的仓库是无法挂载数据卷的

同样是创建docker-compose.yml后输入docker compose up -d创建容器

访问对应地址取得gitea账户授权后如下

drone runner

version: "3"

services:
  runner:
    image: drone/drone-runner-docker:1
    container_name: runner
    environment:
      - DRONE_RPC_PROTO=http
      - DRONE_RPC_HOST=110.41.160.73:3001
      - DRONE_RPC_SECRET=as103208900
      - DRONE_RUNNER_CAPACITY=2
      - DRONE_RUNNER_NAME=my-runner
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 3002:3000

DRONE_RPC_PROTO：部署的服务器协议，如http，https

DRONE_RPC_HOST：部署的服务器地址，如果不是域名的话必须带上端口

DRONE_RPC_SECRET：与drone server通信的密钥

DRONE_RUNNER_CAPACITY：设置同时运行的流水线数量

DRONE_RUNNER_NAME：设置drone runner引用名称

同样是保存成docker-compose.yml后以docker compose up -d命令启动容器

自此，drone与gitea都部署成功

编写.drone.yml

我们创建一个项目，并且用vs添加docker支持，自动生成dockerfile

创建一个.drone.yml文件且必须放在最外层

kind: pipeline
type: docker
name: default

clone:
  skip_verify: true

steps:
  - name: publish
    image: docker:dind
    environment:
      IMAGE: myfirst-cicdtest
      CONTAINERNAME: testcdcidcontainer
    volumes:
      - name: dockersock
        path: /var/run/docker.sock
    commands:
      - docker stop $CONTAINERNAME
      - docker rm $CONTAINERNAME
      - docker rmi $IMAGE
      - docker build -t $IMAGE .
      - docker run -d -p 5056:80 --name $CONTAINERNAME $IMAGE

volumes:
  - name: dockersock
    host:
      path: /var/run/docker.sock

其中steps中为主要构建命令

name：运行步骤的名称

image：依赖的基础镜像

environment：设置的变量，以键值对方式

volumes：挂载的数据卷设置，此处为容器内部地址

commands：运行命令

此处我是以docker部署，所以在每次跑流水线过程前都得先把旧有的容器，镜像删除才能创建新的容器镜像，因此当流水线第一次运行时并不需要这个删除的步骤，但是这种处理方式并不稳妥，实际上较为合理的方式应该是配合k3s或k8s集群，此处的构建只负责打包镜像，由集群来负责部署项目，奈何我暂时不会玩k3s或k8s，等以后有了涉猎之后再来对此处修改。