GitHub Actions 自动化运维实战：从入门到落地

1. 引言

在传统运维模式下，每次发布都要手动登录服务器、执行命令、盯日志，不仅耗时费力，还容易因人为失误导致线上事故。自动化运维正是为了解决这些痛点而生。

GitHub Actions 作为 GitHub 原生的 CI/CD 平台，不仅能完成代码的持续集成与交付，还能承担定时巡检、监控告警、自动部署等运维任务，让「代码即运维」成为现实。

本文将从零开始，带你搭建一套可落地的自动化运维流水线，覆盖部署、监控、多环境发布与安全加固等核心场景。

2. GitHub Actions 核心概念

在动手之前，先快速了解几个贯穿全文的核心术语，后续章节会反复用到：

术语	说明
Workflow	一个自动化流程，由 .github/workflows 目录下的 YAML 文件定义
Job	Workflow 中的任务单元，可并行或串行执行，默认在同一 Runner 上运行
Step	Job 内的最小执行步骤，可以是命令或 Action
Action	可复用的封装步骤，如 actions/checkout、appleboy/scp-action
Runner	执行 Workflow 的服务器，分为 GitHub 托管与自托管两种
Event	触发 Workflow 的事件，如 push、pull_request、schedule
Secrets	仓库级加密变量，用于存放密码、Token 等敏感信息
GITHUB_TOKEN	GitHub 自动生成的临时访问令牌，用于在 Workflow 内调用 API

• Workflow、Job、Step 的基本概念
• 触发方式：push、pull_request、schedule、workflow_dispatch
• Runner 类型：GitHub 托管 Runner 与自托管 Runner
• 常用语法速览：on、jobs、steps、uses、with、env

中英文术语对照表

为方便查阅，这里整理一份常用术语的中英文对照，后续章节将直接使用英文术语：

英文术语	中文含义	常见场景
Workflow	工作流	一个完整的自动化流程定义
Job	任务	工作流中的执行单元
Step	步骤	任务内的最小执行动作
Action	动作	可复用的封装步骤
Runner	运行器	执行工作流的服务器
Event	事件	触发工作流的条件
Trigger	触发	事件触发工作流运行
Schedule	定时任务	按 cron 表达式定时触发
Cron	定时表达式	定义任务执行的时间规则
Artifact	构建产物	构建生成的中间文件
Cache	缓存	加速依赖安装的缓存目录
Secret	密钥	加密存储的敏感变量
Environment	环境	如 dev、staging、production
Deployment	部署	将产物发布到目标环境
Rollback	回滚	恢复到上一可用版本
Self-hosted Runner	自托管运行器	部署在自己服务器上的 Runner
Checkout	检出代码	拉取仓库代码到 Runner
Workflow Dispatch	手动触发	在 GitHub 页面手动运行工作流
Concurrency	并发控制	限制同一工作流的并发运行
Matrix	矩阵策略	多版本、多平台并行构建
Outputs	输出变量	步骤间传递数据
Needs	依赖关系	控制 Job 之间的执行顺序
Permissions	权限声明	控制 GITHUB_TOKEN 的访问范围
Marketplace	应用市场	查找第三方 Action 的官方平台
Notification	通知	向外部渠道发送运行结果
Health Check	健康检查	验证服务是否正常响应
Idempotent	幂等	重复执行产生相同结果

• 通过 SSH 远程执行部署命令
• 使用第三方 Action 简化部署流程
• 部署失败自动回滚策略

完整部署 Workflow 示例

下面是一份可直接套用的完整部署 Workflow，覆盖构建、上传、部署与健康检查四个阶段：

name: Auto Deploy

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install Dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Upload via SCP
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${
   
   {
   
    secrets.SERVER_HOST }}
          username: ${
   
   {
   
    secrets.SERVER_USER }}
          key: ${
   
   {
   
    secrets.SSH_PRIVATE_KEY }}
          source: "dist/*"
          target: "/var/www/myapp"
          strip_components: 1

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${
   
   {
   
    secrets.SERVER_HOST }}
          username: ${
   
   {
   
    secrets.SERVER_USER }}
          key: ${
   
   {
   
    secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/myapp
            pm2 restart myapp
            sleep 5
            curl -fsS http://localhost:3000/health || exit 1

关键点说明：

• cache: npm 自动缓存 node_modules，显著加速后续构建。
• 部署命令末尾的健康检查失败会以非零码退出，从而标记该步骤失败。
• 该示例可直接复制到 .github/workflows/deploy.yml 使用。### SSH 远程部署示例

上传产物后，通常还需要通过 SSH 在服务器上执行部署命令。下面是一个完整的 SSH 部署片段：

- name: Deploy via SSH
  uses: appleboy/ssh-action@v1.0.3
  with:
    host: ${
   
   {
   
    secrets.SERVER_HOST }}
    username: ${
   
   {
   
    secrets.SERVER_USER }}
    key: ${
   
   {
   
    secrets.SSH_PRIVATE_KEY }}
    script: |
      cd /var/www/myapp
      pm2 restart myapp
      curl -fsS http://localhost:3000/health || exit 1

关键点说明：

• appleboy/ssh-action 通过 SSH 在远程服务器上执行 script 中的命令。
• 部署完成后立即执行健康检查，失败则退出并触发告警。
• 若需回滚，可在 script 中切换到上一版本目录并重启服务。### SCP 部署示例

下面是一个使用 SCP 将构建产物上传到云服务器的 Workflow 片段：

name: SCP Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build
        run: |
          npm ci
          npm run build

      - name: Upload via SCP
        uses: appleboy/scp-action@v0.1.7
        with:
          host: ${
   
   {
   
    secrets.SERVER_HOST }}
          username: ${
   
   {
   
    secrets.SERVER_USER }}
          key: ${
   
   {
   
    secrets.SSH_PRIVATE_KEY }}
          source: "dist/*"
          target: "/var/www/myapp"
          strip_components: 1

关键点说明：

• appleboy/scp-action 封装了 SCP 上传逻辑，只需配置主机、用户名与私钥即可。

• 私钥、主机地址等敏感信息一律存放在仓库 Secrets 中，避免明文泄露。

• strip_components: 1 用于去掉 dist/ 前缀，只保留构建产物本身。## 5. 定时任务与监控告警

• 使用 schedule 实现定时巡检

• 健康检查脚本编写与集成

• 失败通知：邮件、钉钉、企业微信、Slack

• 结合 GitHub Issues 自动创建告警单

3. 环境准备与基础配置

在编写第一个 Workflow 之前，需要先完成仓库、密钥与本地调试环境的准备。下面从零开始搭建。

创建仓库与目录结构

在 GitHub 上新建一个仓库（如 myapp），然后在仓库根目录创建 Actions 所需的目录结构：

mkdir -p .github/workflows

一个典型的仓库结构如下：

myapp/
├── .github/
│   └── workflows/
│       └── deploy.yml        # 部署工作流
├── src/                      # 源代码
├── dist/                     # 构建产物（由 CI 生成）
├── package.json
└── package-lock.json

配置仓库 Secrets 与 Variables

在仓库页面进入 Settings → Secrets and variables → Actions，分别配置：

• Secrets（加密变量）：存放 SERVER_HOST、SERVER_USER、SSH_PRIVATE_KEY 等敏感信息。
• Variables（普通变量）：存放 NODE_VERSION、APP_NAME 等非敏感配置。

# 生成 SSH 密钥对（本地执行）
ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/deploy_key

# 将公钥添加到服务器的 authorized_keys
cat ~/.ssh/deploy_key.pub | ssh user@server "cat >> ~/.ssh/authorized_keys"

# 将私钥内容复制到 GitHub Secrets（SSH_PRIVATE_KEY）
cat ~/.ssh/deploy_key

编写第一个 Hello World Workflow

创建 .github/workflows/hello.yml，实现一个最简单的触发流程：

name: Hello World

on:
  push:
    branches: [ main ]
  workflow_dispatch:

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Print Message
        run: echo "Hello, GitHub Actions!"

      - name: Show Repository Info
        run: |
          echo "仓库: ${
   
   { github.repository }}"
          echo "分支: ${
   
   { github.ref_name }}"
          echo "提交: ${
   
   { github.sha }}"

关键点说明：

• on.push.branches 指定触发分支，workflow_dispatch 允许手动触发。
• ${ { github.* }} 是 GitHub 提供的上下文变量，可在运行时获取仓库、分支、提交等信息。
• 推送代码到 main 分支后，可在仓库 Actions 页面看到运行结果。

本地调试技巧：act 工具

act 可以在本地模拟 Gi