使用 GitHub Actions 构建 CI/CD 流水线

使用 GitHub Actions 构建 CI/CD 流水线

初入公司的时候,所经历项目用的 CI/CD 的工具都是 Jenkins。后来慢慢的,发现用 GitHub Actions 实现 CI/CD 的项目越来越多了。
一直对这个东西有点好奇,但也没系统的研究它的应用。巧在,现有项目上有机会让自己从头配置 CI/CD,也就掀开了我对 GitHub Actions 的“神秘面纱”。
仅以此博客分享如何使用 GitHub Actions 构建 CI/CD 流水线以及遇到过的坑和解决办法 。

GitHub Actions 的简单介绍

GitHub Actions 是 GitHub 的自动化平台,它支持各种语言和框架。通过编写 YAML 文件, 用户可以定义在代码库中发生特定事件(比如:Push、Tag等) 时所触发的工作流程,从而帮助用户实现自动化的 CI/CD。

添加 Runner 主机

Runner 主机是执行 GitHub Actions 的核心。为了运行工作流程,我们需要在 Runner 主机。
GitHub Actions 提供了两种类型的 Runner:
托管 Runner:GitHub 提供的 Runner,无需自己维护。
自托管 Runner:在自己的服务器上运行的 Runner,可以根据需要进行定制。
因为自托管 Runner 允许用户在自己的服务器上运行工作流程,提供更多的灵活性和控制。因此我们选择自托管 Runner。

配置 Runner

进入GitHub 仓库的 Settings --> Actions --> Runners --> 点击【New self-hosted-runner】
在该页面,即可看到 Runner 配置流程以及Token, 以 Linux 为例:

$ mkdir actions-runner && cd actions-runner
$ curl -o actions-runner-linux-x64-2.317.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.317.0/actions-runner-linux-x64-2.317.0.tar.gzCopied!
$ tar xzf ./actions-runner-linux-x64-2.317.0.tar.gz
$ ./config.sh --url https://github.com/your-repo --token YOUR_TOKEN

注意:
这里需要根据系统类型,下载不同的安装包(始终记得在 Linux 系统里下载了 Macos runner,死活跑不起来,排查了半天原因)
在 Config Token 这一步配置最好为当前 Runner 添加额外的 Lables(而不是默认生成),以便于后续存在多个 Runner 时更好区分
在这里插入图片描述

运行单个 Runner

如果只有一个 Runner 需要执行,运行如下命令即可:

$ ./run.sh

批量运行多个 Runner

由于项目上一般会存在多个仓库,每个仓库都需要 CI/CD 流水线,因此我们需要在服务器上运行多个 Runner。
为了更好管理,采用 docker-compose 的方式来批量化运行多个 Runner
添加文件夹

 mkdir actions-runner && cd actions-runner

在actions-runner/runners 下按照上述步骤为每个仓库添加的 Runner 主机, eg: actions-runner/runners/service-name1、actions-runner/runners/service-name2

 $ mkdir runners && cd runners

基于 Action Runner 的基础镜像配置 dockerfile

FROM mattermost/actions-runner:2.313.0-0
# 设置工作目录
WORKDIR /home
USER runner
# 复制应用程序代码到容器中
COPY --chown=runner:runner ./runners /home
RUN sudo chown -R runner:runner /home
ENV PATH="/home/runner/.local/bin:$PATH"
# 定义容器启动时要执行的命令
CMD ["./start-runners.sh"]

基于 dockerfile 构建一个 action-runner 的镜像

docker build -t action-runners .

检查镜像构建成功

docker images | grep action-runners

配置 docker-compose 文件

version: "3"
services:
 test_runner1:
   image: action-runners
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
   command: ./service-name1/run.sh
 test_runner2:
   image: action-runners
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
   command: ./service-name2/run.sh

运行 docker-compose 实现批量化运行多个 Runner

docker-compose up -d

查看容器状态

 docker ps

当能看到两个 Runner 容器 STATUS 为 Up 时,即代表容器启动成功

配置 Runner 权限

值得注意的是,考虑到安全性和隔离性,我们在 Runner 容器内设置了专门的用户:Runner 用于运行 GitHub Actions Runner。
为了确保 Runner 用户的权限,我们需要确保 Runner 用户属于与 Docker 套接字所关联的组。
进入 rnnner 所在容器

 sudo docker exec -it [RUNNER 容器id] bash

创建docker组(如果还没有)

 groupadd docker

将runner用户添加到docker组

<
<think>嗯,用户想了解CI/CD流水线的概念和工作原理。首先,我需要回忆一下CI/CD的基本定义。CI是持续集成,CD是持续交付或持续部署,对吧?然后,用户可能想知道整个流水线是如何运作的,各个阶段有什么不同。 根据引用[1],CI/CD流水线分为持续集成、持续交付和持续部署三个阶段。持续集成主要是开发人员频繁地将代码集成到主分支,通过自动化测试和构建来快速发现问题。持续交付则是在此基础上自动化部署到类生产环境,确保可以随时发布。持续部署更进一步,自动将代码部署到生产环境,不需要人工干预。 用户可能还会想知道每个阶段的具体流程,比如在CI阶段,代码提交后如何触发构建和测试,而在CD阶段如何自动化部署。需要引用具体的例子,比如引用[3]提到的GitHub Actions和Jenkins,说明这些工具如何实现自动化流程。同时,要注意区分持续交付和持续部署的区别,避免混淆。 另外,用户可能对CI/CD的好处感兴趣,比如提高效率、减少错误,这些在引用[3]和[4]都有提到。可能还需要解释为什么需要CI/CD,比如应对频繁的代码变更,确保软件质量。 需要确保回答结构清晰,分点解释每个阶段,并结合引用中的例子,比如Jenkins和GitLab Runner的配置,让用户理解实际应用。最后,生成的相关问题要涵盖定义、工作原理、工具选择、挑战和实际应用,帮助用户进一步探索。</think>### CI/CD流水线的定义及工作原理 #### 一、CI/CD流水线的定义 **CI/CD流水线**是一套自动化流程,用于实现软件开发中的持续集成(Continuous Integration, CI)、持续交付(Continuous Delivery)和持续部署(Continuous Deployment)[^1][^2]。其核心目标是通过自动化构建、测试和部署,提升软件交付效率与质量,减少人为操作带来的错误。 #### 二、CI/CD流水线的工作原理 1. **持续集成(CI)阶段** - **触发条件**:开发者将代码提交到版本控制系统(如Git)时触发流水线。 - **核心流程**: - **代码构建**:自动编译代码,生成可执行文件或容器镜像。 - **自动化测试**:运行单元测试、集成测试等,验证代码功能。 - **代码质量检查**:通过静态代码分析工具(如SonarQube)检查代码规范。 - **生成制品**:若通过测试,生成可部署的软件包(如Docker镜像)[^3]。 - **示例工具**:Jenkins、GitHub Actions、GitLab CI。 2. **持续交付(CD)阶段** - **目标**:将通过CI的代码**自动部署到类生产环境**(如预发布环境),准备人工审核后发布。 - **关键步骤**: - **环境部署**:使用基础设施即代码(IaC)工具(如Terraform)配置环境。 - **验收测试**:执行端到端测试(如Selenium)验证系统行为。 - **人工审批**:团队确认后手动触发生产环境部署[^2][^4]。 3. **持续部署(CD)阶段** - **最终环节**:在持续交付基础上,**自动将代码部署到生产环境**,无需人工干预。 - **适用场景**:适用于测试覆盖率高、自动化流程成熟的团队。 - **风险控制**:通过蓝绿部署、金丝雀发布等策略降低风险。 #### 三、核心价值 - **快速反馈**:通过自动化测试在早期发现缺陷,降低修复成本。 - **一致性**:标准化构建和部署流程,避免“本地能跑,生产报错”问题。 - **高频发布**:支持每日多次部署,适应敏捷开发需求。 #### 四、典型工具链 - **CI工具**:Jenkins、GitLab CI、GitHub Actions - **部署工具**:Ansible、Kubernetes(用于容器编排) - **监控工具**:Prometheus、Grafana(实时跟踪部署状态) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值