大家好,这里是白泽。随着 Go 语言在云原生领域大放异彩,开发者逐渐将目光转移到了这门语言上,而容器则是云原生时代最核心的载体。
《Woodpecker CI 设计分析》系列文章将分析开源 CI 引擎 Woodpecker 的架构设计,探究 Go 协程是如何支持由 Workflow
定义的大量 Task
的频繁创建和调度。
而 Task
的一切活动都将在容器内进行。因此这个系列的文章也是帮助你开拓 Go 云原生领域编程的一柄利剑。
这是《Woodpecker CI 设计分析》系列的第一篇文章,主要讲解 Woodpecker 的整体架构设计和体验部署使用,后续文章将讲解核心组件源码设计,并从0开始仿写 Woodpecker 核心组件,欢迎追更~
公众号 「白泽talk」,白泽目前正在打造一个氛围良好的行业交流群,文章的更新也会提前预告,欢迎加入:622383022。
我也开源了一个 Go 学习仓库:包含 Go 各阶段学习文章、读书笔记、电子书、简历模板等,欢迎 star。
🌟 为了帮助理解,本文在讲述知识点时会对比 Woodpecker 和 GitHub Actions 两种持续集成方案,下文 Pipeline 和 Workflow 两个概念在不同的语境下有时可以当作相同语意,注意不要教条。
🌟 关于 CD 这里不展开论述,因为 CD 与 CI 的不同点是业务关注点不同,关注的是 Pipeline 的不同的阶段,对于一个 CI Engine 来说,其实都是可以完成的,换句话说:CI 的阶段能构建镜像,自然也能发布镜像。
接下来对 GitHub 自带的持续集成(GitHub Actions)和 Woodpecker CI 展开介绍与对比,让你对 CI 有一个大致概念。
GitHub 本身也是支持持续集成(CI)的,可以通过在项目 .github/workflows/
路径下创建配置文件定制 Pipeline。
此 GitHub Actions Workflow 在每次推送到 main
分支时触发。它设置一个 Go 环境,构建应用程序,运行测试,最后部署。
# .github/workflows/main.yml
name: CI
?
on:
push:
branches:
- main
?
jobs:
build:
runs-on: ubuntu-latest
?
steps:
- name: Checkout Code
uses: actions/checkout@v2
?
- name: Set up Go
uses: actions/setup-go@v2
with:
go-version: 1.17
id: go
?
- name: Build
run: |
# 在这里执行构建命令
go build
?
- name: Unit Tests
run: |
# 在这里执行单元测试命令
go test ./...
?
- name: Deploy
run: |
# 在这里执行部署命令
echo "Deployment steps go here"
Woodpecker 也是类似的,有一个 Woodpecker 管道配置文件,实现了与 GitHub Actions 相同的 CI 流程。
# .woodpecker.yml
pipelines:
main:
trigger:
branches:
- main
?
steps:
- name: Checkout Code
image: docker://alpine
commands:
- git clone $CI_REPOSITORY_URL $CI_WORKSPACE
?
- name: Set up Go
image: docker://golang:1.17
commands:
- cd $CI_WORKSPACE
- go build
?
- name: Unit Tests
image: docker://golang:1.17
commands:
- cd $CI_WORKSPACE
- go test ./...
?
- name: Deploy
image: docker://alpine
commands:
- echo "Deployment steps go here"
GitHub Actions 提供有限的免费套餐,但对于较大或需要更多资源的项目,需要购买付费套餐。
🌟 Woodpecker 作为开源项目,通常可以在自己的服务器上自行部署和扩展,用户可以按照 Woodpecker 的文档或项目说明进行设置。
看完第二节后,引入了不少 CI/CD 流程中的术语,这里以 Woodpecker 和 GitHub Actions 为例进行对比讲解。
Pipeline:
Workflow:
Step:
语法和配置:
触发条件:
🌟 在 Woodpecker 中,“Server”、“Forge” 和 “Agent” 是三个关键组件,它们各自承担不同的角色和功能:
Server:
功能:
Forge:
功能:
Agent:
功能:
这三个组件协同工作,构成了 Woodpecker CI/CD 系统的基础架构。用户通过 Woodpecker Server 进行配置和管理,Forge 负责与代码仓库集成,Agent 负责执行实际的构建和部署任务。这种分工让 Woodpecker 可以支持多种代码仓库和构建环境,实现灵活的 CI/CD 流程。
🤔 思考几个问题:
🌟 这些问题会在后续分析 Woodpecker 核心组件设计实现的文章中一一解答,同时我们也会手写自己的 Woodpecker。
官方部署文档中提供了多种部署方式,这里使用 docker-compose
部署。docker 的前置知识这里不再赘述。
🌟 往期收藏过百的 Docker 学习文章
docker | jenkins 实现自动化部署项目,后端躺着把运维的钱挣了!(上)
docker | jenkins 自动化CI/CD,后端躺着把运维的钱挣了!(下)
docker-compose.yml
配置文件。version: '3'
?
services:
woodpecker-server:
image: woodpeckerci/woodpecker-server:latest
ports:
- 8000:8000
volumes:
- woodpecker-server-data:/var/lib/woodpecker/
environment:
- WOODPECKER_OPEN=true
- WOODPECKER_HOST=${WOODPECKER_HOST}
- WOODPECKER_GITHUB=true
- WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT}
- WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET}
- WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
?
woodpecker-agent:
image: woodpeckerci/woodpecker-agent:latest
command: agent
restart: always
depends_on:
- woodpecker-server
volumes:
- woodpecker-agent-config:/etc/woodpecker
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WOODPECKER_SERVER=woodpecker-server:9000
- WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
?
volumes:
woodpecker-server-data:
woodpecker-agent-config:
.env
环境变量文件。WOODPECKER_HOST=http://localhost:8000
WOODPECKER_AGENT_SECRET=e61a65af26d998aa303a7b4ce4015ecde83d3caaa3354a91a1120a09e961269e
WOODPECKER_GITHUB_CLIENT=在GitHub生成
WOODPECKER_GITHUB_SECRET=在GitHub生成
🌟 OAuth App 是什么:
在 GitHub 的上下文中,OAuth App 是一种允许开发者使用 GitHub 用户帐户进行身份验证和访问的应用程序。开发者可以创建自己的 OAuth App,并通过 GitHub 的 OAuth 流程获得对用户帐户的有限访问权限。
OAuth App 在 GitHub 上注册后,会获得一个客户端 ID 和一个客户端密钥(Client Secret)。这些凭据用于在用户授权后获取访问令牌,以便应用程序可以代表用户执行某些操作。
在当前场景中,Woodpecker 为了获得访问 GitHub 的能力(监听仓库变动等),需要在 GitHub 开发者配置中心注册为一个 Oauth App。
🌟 创建 OAuth App:
获取 WOODPECKER_GITHUB_CLIENT
和 WOODPECKER_GITHUB_SECRET
的值通常涉及在 GitHub 上创建 OAuth App。以下是如何获取这两个值的步骤:
http://localhost:8000
作为占位符。http://localhost:8000/authorize
作为占位符。.env
文件的 WOODPECKER_GITHUB_CLIENT
和 WOODPECKER_GITHUB_SECRET
:# .env
WOODPECKER_GITHUB_CLIENT=<Your Client ID>
WOODPECKER_GITHUB_SECRET=<Your Client Secret>
运行 docker-compose up -d
命令后将于本机 docker 上成功部署 woodpecker。
http://localhost:8000/
点击 Login。Add repository
可以看到 OAuth 关联账号拥有的仓库列表,查找一个事先准备好的 test-repo。🌟 查看 docker 日志分析原因,提示创建 webhook 需要一个公共可访问的 Host 地址,“localhost” 不满足。
docker logs woodpecker_woodpecker-server_1
代替方案
Gitea 是一个轻量级的、自助的 Git 服务。它是一个开源的、基于 Go 语言的项目,提供了类似于 GitHub、GitLab 等平台的版本控制仓库管理功能。Gitea 允许您在自己的服务器上架设一个 Git 服务,以便团队或个人能够方便地进行代码托管、协作和版本控制。(GitHub 🌟 Star 40k+)
白泽曾经在 Gitea 有过一段时间的实习,后续可以给大家分享一下~
🌟 在本地部署 Gitea 之后,白泽在继续这个 CI 体验流程时遇到了 Woodpecker 和 Gitea 本地通信时一个访问授权 BUG,事后,我发现整个流程也十分值得记录分享。
所以下一篇文章白泽将讲解解决 BUG 的流程,过程中会配合阅读 Gitea & Woodpecker 的代码。为大家梳理使用开源软件遇到问题时的解决思路和步骤。
🌟 未完待续,欢迎追更。
公众号 「白泽talk」,白泽目前正在打造一个氛围良好的行业交流群,文章的更新也会提前预告,欢迎加入:622383022。
我也开源了一个 Go 学习仓库:包含 Go 各阶段学习文章、读书笔记、电子书、简历模板等,欢迎 star。