盐城建设银行网站,上海闵行区租房,外包手工活在哪里拿货,网站内页301重定向怎么做作者 | Addo Zhang来源 | 云原生指北GitHub Actions 是一个功能强大、“免费” 的 CI#xff08;持续集成#xff09;工具。与之前介绍的 Tekton 类似#xff0c;GitHub Actions 的核心也是 Pipeline as Code 也就是所谓的流水线即代码。二者不同的是#xff0c;GitHub Act… 作者 | Addo Zhang来源 | 云原生指北GitHub Actions 是一个功能强大、“免费” 的 CI持续集成工具。与之前介绍的 Tekton 类似GitHub Actions 的核心也是 Pipeline as Code 也就是所谓的流水线即代码。二者不同的是GitHub Actions 本身就是一个 CI 平台用户可以使用代码来定义流水线并在平台上运行而 Tekton 本身是一个用于构建 CI/CD 平台的开源框架。Pipeline as Code既然与代码扯上了关系。那流水线的定义就可繁可简了完全看需求。小到一个 GitHub Pages大到流程复杂的项目都可以使用 GitHub Actions 来构建。本篇文章不会介绍如何使用 GitHub Actions 的如果还未用过的同学可以浏览下官方的文档。今天主要来分享下如何在 Kubernetes 上的自托管资源来执行流水线作业。背 景在介绍 GitHub Actions 的时候免费带上了引号为何其作为一个 CI 工具允许用户定义流水线并在平台上运行需要消耗计算、存储、网络等资源这些运行流水线的机器称为 Runner。GitHub 为不同类等型级的用户每月提供了不同的免费额度额度用完后每分钟 0.008 美元。见下图。不同类型的主机分钟数的消耗倍数也不同Linux 为 1、macOS 为 10、Windows 为 2。拿免费用户来看每月 2000 分钟看似也不少。比如笔者个人就是拿来构建下博客静态页面以及几个简单的应用每个月也用不了太多。但对于企业或者组织来说尤其是当流水线的触发频繁每次代码提交触发、或者项目的单元测试耗时很长bug 引起的或者项目本身的复杂度所致积少成多也会变成一笔不小的开支。那有没有办法使用自己的资源来运行流水线呢有。GitHub Actions Runner 分为两种Github 托管的 Runner 和自托管的 Runner。我们可以将自己的资源作为自托管的 Runner 来运行流水线而且还可以借助 Kubernetes 的能力来管理这些 Runner。同时自托管 Runner 也适合那些对 CI 有更高要求的用户比如更高性能、更多类型的计算资源等等。准备工作Kubernetes 集群我们使用 k3s 快速创建一个单节点的集群。export INSTALL_K3S_VERSIONv1.22.11k3s2
curl -sfL https://get.k3s.io | sh -s - --disable traefik --write-kubeconfig-mode 644 --write-kubeconfig ~/.kube/config使用 Github Actions 构建的项目这里使用之前做的一个 graalvmmaven 的基础镜像仓库来进行测试https://github.com/addozhang/docker-graalvm-maven。GitHub Access Token参考文档创建 Access Token。注意鉴于本演示的需要分配完全的 repo 访问权限。access token创建 RunnerGitHub Actions Runner 的程序源码是开源的GitHub 托管的 Runner 也是使用该程序运行的。Runner 可以是某个仓库使用也可以由组织下的所有仓库共享。鉴于这里演示用的项目我们为上面提到的项目仓库创建 Runner。Runner 在启动时会通过 GitHub API 将自己注册到 GitHub Actions然后不断发送请求到 GitHub 查看是否分配了流水线作业如有则会执行流水线作业Runner 停止运行时需要进行注销的操作。这里的一系列操作都会用到上面创建的 Access Token。要在 Kubernetes 上运行我们要将 Runner 应用以及上面的逻辑打成镜像并以 Deployment 的方式部署到 Kubernetes 中。然后通过 workflow 作业 webhook 查看排队的作业数来决定是否增加或者减少 Deployment 的副本数。听起来就有些复杂但确实是实现的基本方式。这里我们使用一个 Kubernetes controller actions-runner-controller/actions-runner-controller 来实现所有的流程。actions-runner-controller 提供了三种 CRDRunner可以理解为 Pod该 Runner 只能执行一次作业。RunnerDeployments可以理解为 Deployment可以设置要创建的 Runner 数量。Runner 在执行完作业后会销毁然后 Controller 会创建新的 Runner 等待作业调度。RunnerSets可以理解为 StatefulSet也是基于 StatefulSet 来创建 Pod即 Runner提供 StatefulSet 的特性。更多用法可以参考 actions-runner-controller 官方文档。部署 Cert Manageractions-runner-controller 的运行需要使用 cert-mananger。通过下面的命令来部署kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.yaml检查 pod 是否成功启动kubectl get pods -n cert-managerNAME READY STATUS RESTARTS AGE
cert-manager-66b646d76-7b9fz 1/1 Running 0 18s
cert-manager-cainjector-59dc9659c7-rzlrl 1/1 Running 0 18s
cert-manager-webhook-7d8f555998-6zkqp 1/1 Running 0 18s启动 Controller接下来就是启动 controller本文发布时的最新版本是 v0.25.0。使用下面的命令部署 controllerkubectl create -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.25.0/actions-runner-controller.yaml注这里使用的 create 而非 apply。使用 apply 会报类似下面的错误Error from server (Invalid): error when creating https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.25.0/actions-runner-controller.yaml: CustomResourceDefinition.apiextensions.k8s.io runnerdeployments.actions.summerwind.dev is invalid: metadata.annotations: Too long: must have at most 262144 bytes此时pod 无法启动还需要为其创建 Secret 来提供 GitHub Access Tokenexport GITHUB_TOKENTOKEN_HERE
kubectl create secret generic controller-manager \-n actions-runner-system \--from-literalgithub_token${GITHUB_TOKEN}现在可以看到 pod 可以成功运行kubectl get pods -n actions-runner-system
NAME READY STATUS RESTARTS AGE
controller-manager-58c598f64d-27xn6 2/2 Running 0 40s创建 Runner执行下面的命令创建一个名为 building-runner 的 Runner CR。kubectl apply -f - EOF
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:name: building-runner
spec:repository: addozhang/docker-graalvm-mavenenv: []
EOF此时会发现 controller 创建了一个同名的 podkubectl get pods -l actions-runner -n actions-runner-system
NAME READY STATUS RESTARTS AGE
building-runner 2/2 Running 0 16s在仓库的 Settings/Actions/Runners 中可以看到同名的 Runner处于 idle 状态。runner list假如此时启动流水线作业会发现作业并没有调度该 Runner 上。这是因为还没有将作业 Runner 的 label 设置为该 runner 的 labelself-hosted、Linux、 X64。修改流水线定义将 runs-on 指定为 [self-hosted, linux, X64]custom labels然后可以查看作业成功调度到该 runner 上运行schedule job现在再去看 pod 的状态其中的 runner 容器是 Completedkubectl get pods -l actions-runner -n actions-runner-system
NAME READY STATUS RESTARTS AGE
building-runner 1/2 Running 0 3m53s此时再去触发流水线执行作业会一直等待可用的 runner 来执行queued jobrunner 无法重复使用怎么办可重用 RunnerRunnerDeployment 要派上用场了前面提到可以将 RunnerDeployments 理解为 Deployment可以设置要创建的 Runner 数量。Runner 在执行完作业后会销毁然后 Controller 会创建新的 Runner 等待作业调度。kubectl apply -f - EOF
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:name: building-runner
spec:template:spec:repository: addozhang/docker-graalvm-mavenenv: []
EOF使用上面的命令创建 RunnerDeployment 之后controller 会创建新的 podrunner并得到作业的调度完成作业的执行后pod building-runner-9k4cj-ml46v 被销毁新的 pod building-runner-9k4cj-f8twz 被创建并等待作业的调度kubectl get events --sort-bymetadata.creationTimestamp
...
3m7s Normal PodCreated runner/building-runner-9k4cj-ml46v Created pod building-runner-9k4cj-ml46v
3m6s Normal Scheduled pod/building-runner-9k4cj-ml46v Successfully assigned actions-runner-system/building-runner-9k4cj-ml46v to ubuntu-dev1
3m7s Normal RegistrationTokenUpdated runner/building-runner-9k4cj-ml46v Successfully update registration token
3m6s Normal Pulling pod/building-runner-9k4cj-ml46v Pulling image summerwind/actions-runner:latest
3m3s Normal Started pod/building-runner-9k4cj-ml46v Started container docker
3m3s Normal Pulled pod/building-runner-9k4cj-ml46v Successfully pulled image summerwind/actions-runner:latest in 3.06531539s
3m3s Normal Created pod/building-runner-9k4cj-ml46v Created container runner
3m3s Normal Started pod/building-runner-9k4cj-ml46v Started container runner
3m3s Normal Created pod/building-runner-9k4cj-ml46v Created container docker
3m3s Normal Pulled pod/building-runner-9k4cj-ml46v Container image docker:dind already present on machine
2m6s Normal RegistrationTokenUpdated runner/building-runner-9k4cj-f8twz Successfully update registration token
2m6s Normal PodCreated runner/building-runner-9k4cj-f8twz Created pod building-runner-9k4cj-f8twz
2m5s Normal Scheduled pod/building-runner-9k4cj-f8twz Successfully assigned actions-runner-system/building-runner-9k4cj-f8twz to ubuntu-dev1
2m5s Normal Pulling pod/building-runner-9k4cj-f8twz Pulling image summerwind/actions-runner:latest
2m5s Normal Killing pod/building-runner-9k4cj-ml46v Stopping container docker
2m3s Normal Pulled pod/building-runner-9k4cj-f8twz Successfully pulled image summerwind/actions-runner:latest in 2.50468863s
2m3s Normal Created pod/building-runner-9k4cj-f8twz Created container runner
2m3s Normal Started pod/building-runner-9k4cj-f8twz Started container runner
2m3s Normal Pulled pod/building-runner-9k4cj-f8twz Container image docker:dind already present on machine
2m3s Normal Created pod/building-runner-9k4cj-f8twz Created container docker
2m3s Normal Started pod/building-runner-9k4cj-f8twz Started container docker前面创建 RunnerDeployment 的时候没有指定副本数也就是 runner 的数量controller 只创建了一个 Runner。假设这个 RunnerDeployment 是某个组织下多个项目共用的多个项目同时执行作业会怎样这里我重新运行 3 个已经完成的作业模拟作业的并发curl -X POST -H Accept: application/vnd.githubjson -H Authorization: token ${GITHUB_TOKEN} https://api.github.com/repos/addozhang/docker-graalvm-maven/actions/runs/2643982502/rerun
curl -X POST -H Accept: application/vnd.githubjson -H Authorization: token ${GITHUB_TOKEN} https://api.github.com/repos/addozhang/docker-graalvm-maven/actions/runs/2643982274/rerun
curl -X POST -H Accept: application/vnd.githubjson -H Authorization: token ${GITHUB_TOKEN} https://api.github.com/repos/addozhang/docker-graalvm-maven/actions/runs/2643982274/rerun或者 push 几个空的提交到仓库不推荐会有 commit 历史。测试项目随意git commit --allow-empty -m trigger action
git push去 Actions 列表会发现只有一个作业在运行其他两个都是 queued 的等待状态。前面的作业执行完成后后一个作业才会被执行。不支持并发既然是类似 Deployment 的方式运行 runner那是否有类似 HPA水平 pod 自动扩缩容的功能自动伸缩actions-runner-controller 在 3 个 Runner 的 CRD 之外还提供了类似 HPA 的 CRD HorizontalRunnerAutoscaler简称 HRA。HRA 可以根据指标 PercentageRunnersBusy 或者 TotalNumberOfQueuedAndInProgressWorkflowRuns来对 runner 进行扩缩容或者基于 GitHub Eventswebhook来进行扩缩容。这两种都各有优缺点前者指标是通过 GitHub API 轮训等待的作业数实现简单但时效性差后者基于事件触发时效性更佳但是实现复杂需要对外暴露访问端点接收 GitHub Event。这里为了演示使用基于指标的方式进行扩缩容。kubectl apply -f - EOF
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:name: building-runner-autoscaler
spec:scaleDownDelaySecondsAfterScaleOut: 30scaleTargetRef:name: building-runnerminReplicas: 1maxReplicas: 5metrics:- type: PercentageRunnersBusyscaleUpThreshold: 0.75scaleDownThreshold: 0.25scaleUpFactor: 2scaleDownFactor: 0.5
EOF还是通过 API 触发作业模拟并发执行由于轮训间隔比较长默认 1 分钟自动扩容需要等待一段时间kubectl get pods -l actions-runner -n actions-runner-system
NAME READY STATUS RESTARTS AGE
building-runner-k6jlc-dk7gc 2/2 Running 0 1m34s
building-runner-k6jlc-pbwnz 2/2 Running 0 54s
building-runner-k6jlc-nlptp 2/2 Running 0 54s总结GitHub Actions 是个很强大的 CI 工具结合自托管的 Runner 可以在付出较低成本的基础上有更好的体验。本文也只是从满足需求的出发对 “Runner on Kubernetes” 进行了探索。对一个工具从会用到用好还有很长的路要走。但满足当前需求已是足矣。有兴趣的同学可以更进一步思考如何限制 Runner 运行时的资源占用持久化如何实现比如 Maven 构建时的本地库Nodejs 的 node_mudules 如何避免重复下载自动扩缩容能否更加高效往期推荐Redis 内存优化神技小内存保存大数据使用 nginx 轻松管理 kubernetes 资源文件Redis 内存满了怎么办这样置才正确实战 Kubectl 创建 Deployment 部署应用点分享点收藏点点赞点在看
