WEBKT

GitHub Actions自动化部署避坑指南:从代码到服务器,安全高效一路畅通

61 0 0 0

前言:告别手动部署,拥抱自动化时代

1. GitHub Actions 基础:概念、组件与核心流程

2. YAML 文件详解:Workflow 的灵魂

3. 自动化部署实战:从零开始搭建 Workflow

4. 常见问题与避坑指南

5. 高级技巧:自定义 Action 与 Workflow 复用

6. 总结与展望

前言:告别手动部署,拥抱自动化时代

作为一名身经百战的开发者,你是否还在为繁琐的手动部署流程而头疼?每次代码更新,都要经历打包、上传、配置等一系列操作,不仅耗时费力,还容易出错。尤其是在面对复杂的项目和多环境部署时,更是让人感到力不从心。

别担心,GitHub Actions 来了!它就像一位不知疲倦的自动化工程师,能够帮助你轻松实现代码构建、测试、发布等一系列自动化流程,让你彻底告别手动部署的烦恼,把更多的时间和精力投入到更有价值的开发工作中。

本文将以过来人的经验,深入剖析 GitHub Actions 自动化部署的流程和技巧,并分享一些实用的避坑指南,助你快速上手,打造高效、安全的自动化部署方案。

1. GitHub Actions 基础:概念、组件与核心流程

在深入了解自动化部署之前,我们先来认识一下 GitHub Actions 的基本概念和核心组件。

  • Workflow (工作流):一个 Workflow 就是一个完整的自动化流程,例如代码构建、测试、部署等。Workflow 由一个或多个 Job 组成,定义在 .github/workflows 目录下的 YAML 文件中。

  • Job (任务):一个 Job 代表一个独立的执行单元,例如运行单元测试、构建 Docker 镜像等。Job 可以在不同的 Runner 上并行或串行执行。

  • Step (步骤):一个 Step 是 Job 中最小的执行单元,例如运行一条 Shell 命令、执行一个 Action 等。每个 Step 都会在 Runner 上执行,并记录执行结果。

  • Action (动作):Action 是 GitHub Actions 的核心组件,它是一个可重用的自动化任务单元,例如代码检出、依赖安装、代码构建等。GitHub 提供了大量的官方 Action,同时也支持自定义 Action。

  • Runner (运行器):Runner 是执行 Workflow 的服务器,可以是 GitHub 提供的托管 Runner,也可以是自己搭建的自托管 Runner。Runner 会按照 Workflow 的定义,依次执行 Job 和 Step。

核心流程:

  1. 触发 Workflow:可以通过代码提交、Pull Request、定时任务等方式触发 Workflow 的执行。
  2. 选择 Runner:GitHub Actions 会根据 Workflow 的配置,选择合适的 Runner 来执行 Job。
  3. 执行 Job 和 Step:Runner 会按照 Workflow 的定义,依次执行 Job 和 Step,并记录执行结果。
  4. 输出结果:Workflow 执行完成后,会输出执行结果,例如成功、失败、警告等。

2. YAML 文件详解:Workflow 的灵魂

Workflow 的定义都写在 YAML 文件中,它是 GitHub Actions 的灵魂。一个 YAML 文件通常包含以下几个部分:

  • name:Workflow 的名称,用于在 GitHub Actions 界面上显示。
  • on:触发 Workflow 的事件,例如 pushpull_requestschedule 等。
  • jobs:定义 Workflow 中包含的 Job,每个 Job 都有一个唯一的 ID。
  • runs-on:指定 Job 运行的 Runner 类型,例如 ubuntu-latestwindows-latestmacos-latest 等。也可以使用自托管 Runner 的标签。
  • steps:定义 Job 中包含的 Step,每个 Step 都有一个唯一的 ID。
  • uses:指定 Step 使用的 Action,可以是 GitHub 官方 Action,也可以是第三方 Action,甚至是自定义 Action。
  • with:为 Action 传递参数,例如 repositorytokenpath 等。
  • env:定义环境变量,可以在 Job 和 Step 中使用。
  • secrets:定义敏感信息,例如 API Key、数据库密码等,GitHub 会对这些信息进行加密存储。

示例 YAML 文件:

name: Deploy to Production
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install dependencies
run: npm install
- name: Build project
run: npm run build
- name: Deploy to server
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.SERVER_IP }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script:
cd /var/www/production
git pull origin main
npm install
npm run build
pm2 restart all

YAML 文件编写技巧:

  • 格式规范:YAML 文件对格式要求非常严格,必须注意缩进和空格,否则会导致 Workflow 执行失败。
  • 注释:在 YAML 文件中添加适当的注释,可以提高代码的可读性和可维护性。
  • 变量:使用变量可以使 YAML 文件更加灵活,例如可以使用 GITHUB_SHA 获取当前 Commit 的 SHA 值。
  • Secrets:不要将敏感信息直接写在 YAML 文件中,而是使用 Secrets 进行管理。

3. 自动化部署实战:从零开始搭建 Workflow

接下来,我们以一个简单的 Node.js 项目为例,演示如何从零开始搭建一个自动化部署 Workflow。

项目准备:

  1. 创建一个 Node.js 项目,包含 package.json 文件。
  2. 在 GitHub 上创建一个仓库,并将代码推送到仓库中。
  3. 在服务器上安装 Node.js 和 pm2,并配置好 SSH 访问。

创建 Workflow 文件:

  1. 在项目根目录下创建一个 .github/workflows 目录。
  2. .github/workflows 目录下创建一个 deploy.yml 文件。

编写 YAML 文件:

将以下代码复制到 deploy.yml 文件中,并根据实际情况进行修改。

name: Deploy to Production
on:
push:
branches:
- main
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '16'
- name: Install dependencies
run: npm install
- name: Build project
run: npm run build
- name: Deploy to server
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.SERVER_IP }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script:
cd /var/www/production
git pull origin main
npm install
npm run build
pm2 restart all

配置 Secrets:

  1. 在 GitHub 仓库的 Settings 页面,选择 Secrets -> Actions。
  2. 添加以下 Secrets:
    • SERVER_IP:服务器的 IP 地址。
    • SERVER_USER:服务器的用户名。
    • SSH_PRIVATE_KEY:服务器的 SSH 私钥。

提交代码:

deploy.yml 文件提交到 GitHub 仓库的 main 分支,触发 Workflow 的执行。

查看执行结果:

在 GitHub 仓库的 Actions 页面,可以查看 Workflow 的执行结果。如果一切顺利,你的代码就会自动部署到服务器上。

4. 常见问题与避坑指南

在使用 GitHub Actions 进行自动化部署的过程中,可能会遇到各种各样的问题。下面是一些常见问题和避坑指南:

  • Workflow 执行失败
    • 检查 YAML 文件格式是否正确,特别是缩进和空格。
    • 检查 Action 是否存在,以及参数是否正确。
    • 查看 Workflow 的日志,找到错误信息,并根据错误信息进行排查。
  • Runner 资源不足
    • 如果使用 GitHub 提供的托管 Runner,可能会因为资源不足而导致 Workflow 执行缓慢甚至失败。
    • 可以考虑使用自托管 Runner,并根据实际需求配置 Runner 的硬件资源。
  • 权限问题
    • 确保 Runner 具有足够的权限来执行 Workflow 中的任务。
    • 例如,如果需要访问服务器上的文件,需要确保 Runner 具有相应的读写权限。
  • 网络问题
    • 确保 Runner 可以访问外部网络,例如可以访问 GitHub、npm registry 等。
    • 如果需要访问内部网络,需要配置 Runner 的网络代理。
  • 缓存问题
    • 可以使用 actions/cache Action 来缓存依赖,加快 Workflow 的执行速度。
    • 但需要注意缓存的有效期,避免缓存过期导致 Workflow 执行失败。
  • 安全问题
    • 不要将敏感信息直接写在 YAML 文件中,而是使用 Secrets 进行管理。
    • 定期更新 Runner 的软件和依赖,防止安全漏洞。

5. 高级技巧:自定义 Action 与 Workflow 复用

除了使用 GitHub 提供的 Action,我们还可以自定义 Action,以满足更复杂的需求。自定义 Action 可以使用 JavaScript、Docker 等技术实现。

自定义 Action 示例:

const core = require('@actions/core');
const github = require('@actions/github');
try {
// `who-to-greet` input defined in action metadata file
const nameToGreet = core.getInput('who-to-greet');
console.log(`Hello ${nameToGreet}!`);
const time = (new Date()).toTimeString();
core.setOutput("time", time);
// Get the JSON webhook payload for the event that triggered the workflow
const payload = JSON.stringify(github.context.payload, undefined, 2)
console.log(`The event payload: ${payload}`);
} catch (error) {
core.setFailed(error.message);
}

Workflow 复用:

可以使用 uses 关键字来复用其他 Workflow,例如:

name: My Workflow
on:
push:
branches:
- main
jobs:
build:
uses: ./.github/workflows/build.yml
deploy:
needs: build
uses: ./.github/workflows/deploy.yml
with:
environment: production

6. 总结与展望

GitHub Actions 是一款强大的自动化工具,可以帮助我们实现代码构建、测试、发布等一系列自动化流程,提高开发效率,减少人为错误。掌握 GitHub Actions 的基本概念、核心组件和使用技巧,可以让我们更好地利用它来构建高效、安全的自动化部署方案。

随着云原生技术的不断发展,GitHub Actions 的应用场景也将越来越广泛。未来,我们可以期待 GitHub Actions 能够提供更多的功能和更强大的性能,为开发者带来更好的体验。

希望本文能够帮助你快速上手 GitHub Actions,并将其应用到实际项目中。如果你在学习和使用过程中遇到任何问题,欢迎留言交流。

DevOps老司机 GitHub Actions自动化部署CI/CD

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9477